![]() ![]() ![]() ![]() ![]() |
Top Contents Index Glossary |
Link Summary
|
Exercise Links
Glossary Terms |
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.log
.
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 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 Proposals.
For now, though, let's simply rename the title
element in slideshow.dtd
.
Note:
The XML shown here is contained inslideshow3.dtd
andslideSample09.xml
, which referencescopyright.xml
. The results of processing are shown inEcho10-09.log
.
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.log
.
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.
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.)
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 Manipulating Document Contents with the Document Object Model.
![]() ![]() ![]() ![]() ![]() |
Top Contents Index Glossary |