Datasheet

supports a particular feature or property. XMLParserConfiguration adds APIs that let you do several cat-

egories of tasks:

❑ Configuration—This API provides methods to tell configuration clients the set of supported

features and properties. It also adds methods for changing the values of features and properties.

❑ Sink management—There are methods that allow configuration clients to register sinks for the

three major pipeline interfaces in the configuration. Clients can also ask for the currently regis-

tered sink on a per-interface basis.

❑ Helper services—XMLParserConfiguration assumes that configuration-wide services and data

are used by the XMLComponents in the configuration. Examples of these services include error

reporting as defined by the XMLErrorHandler interface and entity resolution as defined by the

XMLEntityResolver interface.

❑ Parsing kickoff—XMLParserConfiguration provides methods for starting the process of pars-

ing XML from an XMLInputSource.

Let’s look back at the diagram of Xerces. On top of the XMLParserConfiguration sits a Xerces parser

class. This class is a sink for XMLDocumentHandler, XMLDTDHandler, and

XMLDTDContentModelHandler. It registers itself as the sink for the various parts of the pipeline. The

implementation of the various callback methods takes care of translating between the XNI callback and

the parser API being implemented. For a SAX parser, the translation is pretty straightforward, consisting

mostly of converting QNames and XMLStrings into Java Strings. A DOM parser is little more difficult

because the callbacks need to build up the nodes of the DOM tree in addition to translating the XNI

types.

Remember that we said the diagram was simplified. The Xerces SAXParser and DOMParser are actually

implemented as a hierarchy of subclasses, with functionality layered between the various levels of the

class hierarchy. The reason for doing this is to allow developers to produce their own variants of

SAXParser and DOMParser with as little work as necessary.

There’s only one part of the diagram we haven’t discussed. At bottom right is a section labeled support

components. We’ve already talked a little about helper components when we discussed

XMLParserConfiguration. In that discussion, we were looking at components that were likely to be used

by any parser configuration we could think have. Other support components are used only by a particu-

lar parser configuration. These are used internally by the parser configuration but are known by some

number of the XMLComponents in the pipelines. Examples of these kinds of components include sym-

bol tables and components dedicated to managing the use of namespaces throughout the configuration.

These support components are provided to the pipeline components as properties, so they are assigned

URI strings that mark them as being for internal use and then set using the configuration-wide property-

setting mechanism.

Xerces2 XNI Components

XNI as we’ve discussed it is really a framework. The interfaces describe how the pieces of the framework

interact. You can think of Xerces2 as a very useful reference implementation of the XNI framework. If

you’re going to build an application using XNI, you may find it useful to reuse some of the components

from the Xerces2 reference implementation. These components have the advantage of being heavily

tested and debugged, so you can concentrate on implementing just the functionality you need. Here are

some of the most useful components from Xerces2.

Xerces

01 543555 Ch01.qxd 11/5/03 9:40 AM Page 41