Parsing with a DTD

After the XML declaration, the document prolog can include a DTD, reference an external DTD, or both. In this section, you'll see the effect of the DTD on the data that the parser delivers to your application.

DTD's Effect on the Nonvalidating Parser

In this section, you'll use the Echo program to see how the data appears to the SAX parser when the data file references a DTD.

Running the Echo program on your latest version of slideSample.xml shows that many of the superfluous calls to the characters method have now disappeared.

  ...
>
PROCESS: ...
CHARS:
  ELEMENT:        <slide
    ATTR: ...
  >
      ELEMENT:        <title>
      CHARS:        Wake up to ...
      END_ELM:        </title>
  END_ELM:        </slide>
CHARS:
  ELEMENT:        <slide
    ATTR: ...
  >
  ...

  ...
>
PROCESS: ...
  ELEMENT:        <slide
    ATTR: ...
  >
      ELEMENT:        <title>
      CHARS:        Wake up to ...
      END_ELM:        </title>
  END_ELM:        </slide>
  ELEMENT:        <slide
    ATTR: ...
  >
  ...

It is evident that the whitespace characters that were formerly being echoed around the slide elements are no longer being delivered by the parser, because the DTD declares that slideshow consists solely of slide elements:

  <!ELEMENT slideshow (slide+)>

Tracking Ignorable Whitespace

Now that the DTD is present, the parser is no longer calling the characters method with whitespace that it knows to be irrelevant. From the standpoint of an application that is interested in processing only the XML data, that is great. The application is never bothered with whitespace that exists purely to make the XML file readable.

On the other hand, if you were writing an application that was filtering an XML data file and if you wanted to output an equally readable version of the file, then that whitespace would no longer be irrelevant: it would be essential. To get those characters, you add the ignorableWhitespace method to your application. You'll do that next.

To process the (generally) ignorable whitespace that the parser is seeing, add the following highlighted code to implement the ignorableWhitespace event handler in your version of the Echo program:

public void characters (char buf[], int offset, int len)
... 
} 
public void ignorableWhitespace char buf[], int offset, int Len)
throws SAXException
{
  nl(); 
  emit("IGNORABLE");
} 
public void processingInstruction(String target, String data)
...

This code simply generates a message to let you know that ignorable whitespace was seen.

Note: Again, not all parsers are created equal. The SAX specification does not require that this method be invoked. The Java XML implementation does so whenever the DTD makes it possible.

ELEMENT: <slideshow
  ATTR: ...
>
IGNORABLE
IGNORABLE
PROCESS: ...
IGNORABLE
IGNORABLE
  ELEMENT: <slide
    ATTR: ...
  >
  IGNORABLE
    ELEMENT: <title>
    CHARS:   Wake up to ...
    END_ELM: </title>
  IGNORABLE
  END_ELM: </slide>
IGNORABLE
IGNORABLE
  ELEMENT: <slide
    ATTR: ...
  >
  ...

Here, it is apparent that the ignorableWhitespace is being invoked before and after comments and slide elements, whereas characters was being invoked before there was a DTD.

Cleanup

Now that you have seen ignorable whitespace echoed, remove that code from your version of the Echo program. You won't need it any more in the exercises that follow.

Empty Elements, Revisited

Now that you understand how certain instances of whitespace can be ignorable, it is time revise the definition of an empty element. That definition can now be expanded to include

where there is whitespace between the tags and the DTD says that the whitespace is ignorable.

Echoing Entity References

When you wrote slideSample06.xml, you defined entities for the singular and plural versions of the product name in the DTD:

<!ENTITY product  "WonderWidget">
<!ENTITY products "WonderWidgets">

<title>Wake up to &products;!</title>

Now it's time to see how they're echoed when you process them with the SAX parser.

When you run the Echo program on slideSample06.xml, here is the kind of thing you see:

ELEMENT:        <title>
CHARS:        Wake up to WonderWidgets!
END_ELM:        </title>

Echoing the External Entity

In slideSample07.xml, you defined an external entity to reference a copyright file.

When you run the Echo program on that version of the slide presentation, here is what you see:

...
END_ELM: </slide>
ELEMENT: <slide
  ATTR: type        "all"
>
  ELEMENT: <item>
  CHARS: 
This is the standard copyright message that our lawyers
make us put everywhere so we don't have to shell out a
million bucks every time someone spills hot coffee in their
lap...
  END_ELM: </item>
END_ELM: </slide>
...

Note that the newline that follows the comment in the file is echoed as a character, but the comment itself is ignored. That is why the copyright message appears to start on the next line after the CHARS: label instead of immediately after the label: the first character echoed is actually the newline that follows the comment.

Summarizing Entities

An entity that is referenced in the document content, whether internal or external, is termed a general entity. An entity that contains DTD specifications that are referenced from within the DTD is termed a parameter entity. (More on that later.)

An entity that contains XML (text and markup), and is therefore parsed, is known as a parsed entity. An entity that contains binary data (such as images) is known as an unparsed entity. (By its nature, it must be external.) We'll discuss references to unparsed entities later, in Using the DTDHandler and EntityResolver.