The Xerces Native Interface core contains a series of interfaces and classes designed to communicate a document's "streaming" information set. This page documents the API available for receiving this information in the following sections:
A few examples are also included to illustrate the use of the streaming information set:
For information regarding the parser configuration framework, refer to the Parser Configuration documentation.
The document information is communicated using the
XMLDocumentHandler interface. In addition, the
XMLDocumentFragmentHandler interface is included
to get information regarding document fragments. Programmers
already familiar with the SAX programming interfaces should
be immediately comfortable programming to the Xerces Native
Interface. However, XNI does not depend on the SAX interfaces
and classes.
org.apache.xerces.xni
package.
Communicates document structure and content information. This is the most important handler interface in the Xerces Native Interface.
Communicates information about a document fragment. This interface is provided for convenience in defining a document fragment but is not required to be used by a compliant XNI parser component or configuration.
Besides the handler interfaces there are several related interfaces and classes. All of these are described below.
Represents a generic Xerces Native Interface exception.
Note:
This exception extends java.lang.RuntimeException.
Therefore, even though all of the handler interface methods can
throw this type of exception, it is not explicitly required to
be caught. Since XNI is intended to be an internal set of
interfaces, it is expected that XNI implementations will provide
a catch block for this exception at the top level so that XNI
exceptions do not "leak" out to the application code.
This interface enables arbitrary information to be passed through the pipeline on various calls from one component to another. XNI tries to model, as close as is feasible, the information made available by the W3C's InfoSet specification. The Augmentations interface is intended to permit components to augment the infoset for some document at almost any given point. Many other XNI interfaces besides the DocumentHandler support Augmentations parameters.
One kind of particularly useful Infoset augmentation is provided through the Post-Schema validation Infoset. For information about Xerces2's support of the PSVI, and how Augmentations are used in a well-defined way to permit this support, see the documentation for the PSVI Writer and PSVI Configuration samples.
This interface serves to gather together information relevant to any kind of XML resource (external entity, notation, schema grammar, etc.). There are five fields in this interface:
schemaLocation attribute as the case may be)
should be resolved relative to.
schemaLocation) of the entity
which this object relates to.
schemaLocation) after being subjects to relative
URI expansion. SAX programmers will be familiar with this
concept from the SAX Locator interface, for example; this
property maps to the systemId property of that
interface.
As in the case of other XNI objects, XMLResourceIdentifiers cannot be depended upon to retain their values between calls; hence, callees should extract whatever information they need from them (or clone the object) before returning control back to the parser.
This interface is used to communicate the document location to the various handler interfaces. The application can use the methods on this interface to query the public, literal system, and expanded system base system identifier as well as the line number, column number and the encoding of the entity currently being parsed.
A locator is passed as a parameter in the first method called
by the XMLDocumentHandler,
XMLDocumentFragmentHandler, and
XMLDTDHandler interfaces.
Note: Parser components that emit document information are not required to provide a locator object. However, the Xerces2 reference implementation does provide a locator to registered handlers.
The QName object is a structure of qualified name information.
Note: The fields of this object have public visibility but should be considered to be read-only to all methods that are passed this object. The caller that creates and passes the QName object "owns" the data. Therefore, callees should not retain a reference to the passed object and are required to copy the references contained in the object if the data is to be used beyond the scope of the method call.
This interface represents the collection of attributes that is
passed to the startElement and emptyElement
methods of the XMLDocumentHandler and
XMLDocumentFragmentHandler interfaces. This
collection of attributes contains all of the information about
the attributes of an element (except order) and is editable.
This interface is also capable of storing information about entities appearing in the attribute value. However, it should be noted that if entity information is set for an attribute, then the non-normalized value of the attribute must also be stored because the offsets and lengths of entities in the attribute have no meaning for the normalized value.
The XMLString object is a structure for holding text information. This object allows the underlying implementation to pass text information by using its own internal character buffer without creating new String objects or copying the data.
Note: The fields of this object have public visibility but should be considered to be read-only to all methods that are passed this object. The caller that creates and passes the XMLString object "owns" the data. Therefore, callees should not retain a reference to the passed object and are required to copy the information contained in the object if the data is to be used beyond the scope of the method call. Also, callees should never modify the contents of the character array directly as that could adversely affect the operation of the caller.
Namespace context information for document fragments. This
object is passed to the first method of the
XMLDocumentFragmentHandler interface.
The DTD information is communicated through two interfaces:
XMLDTDHandler and XMLDTDContentModelHandler.
The first handler interface passes the basic DTD information
whereas the second handler interface breaks down each element
declaration content model into separate callbacks.
Communicates basic DTD information such as element and attribute declarations. The implementor of this interface can also be informed of characters within an ignored conditional section.
Breaks down each element declaration's content model into
a set of separate methods so that handlers don't have to
reparse the content model string given in the
XMLDTDHandler#elementDecl(String,String) method.
This separation also helps those applications that want to
know boundaries of entities when used as part of an element's
content model.
The following examples demonstrate the basic use of the various XNI handler interfaces.
The following example demonstrates a basic pass-through document handler filter. This filter receives document handler events and passes them through to the next document handler.
The following code extends the pass-through document handler filter to upper-case all of the element names.