Home
TOC Index |
Parsing the Parameterized DTD
This section uses the Echo program to see what happens when you reference
xhtml.dtd
inslideshow.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 inEcho10-08.txt
. (The browsable version isEcho10-08.html
.)
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: .../slideshow.dtd Element type "title" must not be declared more than once.
Note: The message above was generated by the JAXP 1.2 libraries. If you are using a different parser, the error message is likely to be somewhat different.
It seems that
xhtml.dtd
defines atitle
element which is entirely different from thetitle
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 atitle
element that is intended to be the document title, so we can't avoid the conflict by changingxhtml.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 inslideshow.dtd
.
Note: The XML shown here is contained inslideshow3.dtd
andslideSample09.xml
, which referencescopyright.xml
andxhtml.dtd
. The results of processing are shown inEcho10-09.txt
. (The browsable versions areslideshow3-dtd.html
,slideSample09-xml.html
,copyright-xml.html
,xhtml-dtd.html, and Echo10-09.html
.)
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 inslideshow.dtd
toslide-title
:<!ELEMENT slide (image?,slide
-title?, item*)> <!ATTLIST slide type (tech | exec | all) #IMPLIED > <!-- Defines the %inline; declaration --> <!ENTITY % xhtml SYSTEM "xhtml.dtd"> %xhtml; <!ELEMENTslide
-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 thetitle
element in the "slideshow namespace" (slide-title
, really) no longer conflicts with thetitle
element inxhtml.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 applications, you can skip ahead to Document Object Model.
Home
TOC Index |
This tutorial contains information on the 1.0 version of the Java Web Services Developer Pack.
All of the material in The Java Web Services Tutorial is copyright-protected and may not be published in other works without express written permission from Sun Microsystems.