After a rather extensive look at EntityResolver, I'm going to cruise through DTDHandler (also in org.xml.sax). In almost nine years of extensive SAX and XML programming, I've used this interface only oncein writing JDOM (covered in )and even then, it was a rather obscure case. Still, if you work with unparsed entities often, are into parser internals, or just want to get into every nook and cranny of the SAX API, then you need to know about DTDHandler. The interface is shown in all its simplicity in .

This handler is concerned with the declaration of certain XML types, rather than the actual content of those entities (if and when they are resolved)

Java ScreenShot

The DTDHandler interface allows you to receive notification when a reader encounters an unparsed entity or notation declaration. Of course, both of these events occur in DTDs, not XML documents, which is why this is called DTDHandler. The two methods listed in do exactly what you would expect. The first reports a notation declaration, including its name, public ID, and system ID. Remember the NOTATION structure in DTDs? (Flip back to if you're unclear.) 

<!NOTATION jpeg SYSTEM "images/jpeg">

The second method provides information about an unparsed entity declaration, which looks as follows: 

<!ENTITY stars_logo SYSTEM "http://www.nhl.com/img/team/dal38.gif"
 NDATA jpeg>

In both cases, you can take action at these occurrences if you create an implementation of DTDHandler and register it with your reader through the XMLReader's setDTDHandler( ) method. This is generally useful when writing low-level apps that must either reproduce XML content (such as an XML editor), or when you want to build up some Java representation of a DTD's constraints (such as in a data binding implementation). In most other situations, it isn't something you will need very often.

Handlers Aren't Features

You need to carefully fix in your mind the difference between a feature, which affects what processing a parser does, and a handler, which simply allows your code to respond to certain events in that processing. As an example, realize that registering (or not registering) a ContentHandler doesn't affect whether processing instructions are parsed; even implementing (or not implementing) the processingInstruction( ) callback doesn't have an effect. The same is true of ErrorHandler; whether you report errors or not, they still can occur. Where this distinction becomes vital is in working with the DTDHandler; implementing or registering an implementation of this handler has no effect on whether validation of your document occurs. DTDHandler doesn't do anything but provide notification of notation and unparsed entity declarations! It's a feature that sets validation, not a handler instance: 

reader.setFeature("http://xml.org/sax/features/validation", true);

Anything less than this (short of a parser validating by default) won't get you validation.