Datasheet

XMLString, XNIException, Augmentations, QName, XMLAttributes, XMLLocator,

XMLResourceIdentifier, and NamespaceContext are all used by one of the four major interfaces

(XMLDocumentHandler, XMLDocumentFragmentHandler, XMLDTDHandler, and

XMLDTDContentModelHandler).

If you look at the XMLComponent interface, you’ll see that it really just defines methods for setting con-

figuration settings on a component. Not surprisingly, it uses a feature and property interface reminiscent

of SAX. The biggest addition is a pair of methods that return an array of the features/properties sup-

ported by the component. What may surprise you is that the interface doesn’t say anything about the

callback interfaces for the pipeline. This is intentional, because not all components are in all pipelines—

that’s part of the rationale for breaking up the pipeline interfaces, so that components can implement the

smallest set of functionality they require.

To implement a real component that can be a part of a pipeline, you need more interfaces. These inter-

faces are found in org.apache.xerces.xni.parser. The callback interfaces define what it means to be a

recipient or sink for streaming information set events. Components that act as sinks sit at the end of the

pipeline. That means you need interfaces for components at the start of the pipeline and for components

in the middle. Components at the start of the pipeline are sources of streaming information set events, so

they need to be connected to an event sink. The interface for these components has a pair of methods

that let you get and set the sink to which the source is connected. There are three of these source inter-

faces, one for each of the major pipeline interfaces (XMLDocumentFragmentHandler is considered

minor because document fragments appear so infrequently):

❑ XMLDocumentSource for XMLDocumentHandler

❑ XMLDTDSource for XMLDTDHandler

❑ XMLDTDContentModelSource for XMLDTDContentModelHandler

Now, defining interfaces for components in the middle is easy. These components must implement both

the source and sink (handler) interfaces for the pipeline. That gives XMLDocumentFilter, which imple-

ments XMLDocumentSource and XMLDocumentHandler. XMLDTDFilter and

XMLDTDContentModelFilter are defined in a similar way.

At this point it’s a little clearer what an XNI pipeline is. Using the DocumentHandler as an example, a

pipeline is an instance of XMLDocumentSource connected to some number of instances of

XMLDocumentFilter that are chained together. The last XMLDocumentFilter is connected to an instance

of XMLDocumentHandler, which provides the final output of the pipeline. The instance of

XMLDocumentSource takes the XML document as input. The next question you should be thinking

about is how the pipeline is constructed, connected, and started up.

XNI Pipeline Interfaces

XNI provides interfaces you can use to take care of these matters. You aren’t by any means required

to do this—you could do it with custom code, but you’ll probably find that you end up duplicating

the functionality provided by XNI. The interfaces for managing XMLComponents are also found

in org.apache.xerces.xni.parser. Let’s call a pipeline of XMLComponents a configuration. The

interface for managing a configuration is called XMLParserConfiguration. This interface extends

XMLComponentManager, which provides a simple API for querying whether a set of components

Chapter 1

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