Home TOC

Parsing the Parameterized DTD

This section uses the Echo program to see what happens when you reference xhtml.dtd in slideshow.dtd. It also covers the kinds of warnings that are generated by the SAX parser when a DTD is present.

---

Note: The output described in this section is contained in Echo10-08.

---

When you try to echo the slide presentation, you find that it now contains a new error. The relevant part of the output is shown here (formatted for readability):

<?xml version='1.0' encoding='UTF-8'?>	
** Parsing error, line 22, 	
   uri file:.../slideshow.dtd	
Element "title" was already declared.	
org.xml.sax.SAXParseException: ...
 

It seems that xhtml.dtd defines a title element which is entirely different from the title element defined in the slideshow DTD. Because there is no hierarchy in the DTD, these two definitions conflict.

---

Note: The Modularized XHTML DTD also defines a title element that is intended to be the document title, so we can't avoid the conflict by changing xhtml.dtd--the problem would only come back to haunt us later.

---

You could also use XML namespaces to resolve the conflict, or use one of the more hierarchical schema proposals described in Schema Standards. For now, though, let's simply rename the title element in slideshow.dtd.

---

Note: The XML shown here is contained in slideshow3.dtd and slideSample09.xml, which references copyright.xml and xhtml.dtd. (The browsable versions are slideshow3-dtd.html, slideSample09-xml.html, copyright-xml.html, and xhtml-dtd.html.) The results of processing are shown in Echo10-09.

---

To keep the two title elements separate, we'll resort to a "hyphenation hierarchy". Make the changes highlighted below to change the name of the title element in slideshow.dtd to slide-title:

<!ELEMENT slide (image?, slide-title?, item*)>	
<!ATTLIST slide 	
         type   (tech | exec | all) #IMPLIED	
>
 
<!-- Defines the %inline; declaration -->	
<!ENTITY % xhtml SYSTEM "xhtml.dtd">	
%xhtml;
 
<!ELEMENT slide-title (%inline;)*>
 

The next step is to modify the XML file to use the new element name. To do that, make the changes highlighted below:

...	
<slide type="all">	
<slide-title>Wake up to ... </slide-title>	
</slide>
 
...
 
<!-- OVERVIEW -->	
<slide type="all">	
<slide-title>Overview</slide-title>	
<item>...
 

Now run the Echo program on this version of the slide presentation. It should run to completion and display output like that shown in Echo10-09.

Congratulations! You have now read a fully validated XML document. The changes you made had the effect of putting your DTD's title element into a slideshow "namespace" that you artificially constructed by hyphenating the name. Now the title element in the "slideshow namespace" (slide-title, really) no longer conflicts with the title element in xhtml.dtd. In the next section of the tutorial, you'll see how to do that without renaming the definition. To finish off this section, we'll take a look at the kinds of warnings that the validating parser can produce when processing the DTD.

DTD Warnings

As mentioned earlier in this tutorial, warnings are generated only when the SAX parser is processing a DTD. Some warnings are generated only by the validating parser. The nonvalidating parser's main goal is operate as rapidly as possible, but it too generates some warnings. (The explanations that follow tell which does what.)

The XML specification suggests that warnings should be generated as result of:

• Providing additional declarations for entities, attributes, or notations. (Such declarations are ignored. Only the first is used. Also, note that duplicate definitions of elements always produce a fatal error when validating, as you saw earlier.)
• Referencing an undeclared element type.

  (A validity error occurs only if the undeclared type is actually used in the XML document. A warning results when the undeclared element is referenced in the DTD.)

• Declaring attributes for undeclared element types.

The Java XML SAX parser also emits warnings in other cases, such as:

• No <!DOCTYPE ...> when validating.
• Referencing an undefined parameter entity when not validating.

  (When validating, an error results. Although nonvalidating parsers are not required to read parameter entities, the Java XML parser does so. Since it is not a requirement, the Java XML parser generates a warning, rather than an error.)

• Certain cases where the character-encoding declaration does not look right.

At this point, you have digested many XML concepts, including DTDs, external entities. You have also learned your way around the SAX parser. The remainder of the SAX tutorial covers advanced topics that you will only need to understand if you are writing SAX-based applications. If your primary goal is to write DOM-based apps, you can skip ahead to Document Object Model (page 163).

Home TOC