The Xerces Native Interface (XNI) is an internal API that is independent of other XML APIs and is used to implement the Xerces family of parsers. XNI allows a wide variety of parsers to be written in an easy and modular fashion. The XNI samples included with Xerces are simple examples of how to program using the XNI API. However, for information on how to take full advantage of this powerful framework, refer to the XNI Manual.

Basic XNI samples:

• xni.Counter
• xni.DocumentTracer
• xni.Writer
• xni.PSVIWriter
• xni.XMLGrammarBuilder

• xni.PassThroughFilter
• xni.UpperCaseFilter

Parser configuration samples:

• xni.parser.NonValidatingParserConfiguration
• xni.parser.AbstractConfiguration

• xni.parser.CSVConfiguration
• xni.parser.CSVParser
• xni.parser.PSVIConfiguration
• xni.parser.PSVIParser

Sample xerces.properties

• xni/xerces.properties

Most of the XNI samples have a command line option that allows the user to specify a different XNI parser configuration to use. In order to supply another parser configuration besides the default Xerces StandardParserConfiguration, the configuration must implement the org.apache.xerces.xni.parser.XMLParserConfiguration interface.

A sample XNI counter. The output of this program shows the time and count of elements, attributes, ignorable whitespaces, and characters appearing in the document.

This class is useful as a "poor-man's" performance tester to compare the speed and accuracy of various parser configurations. However, it is important to note that the first parse time of a parser will include both VM class load time and parser initialization that would not be present in subsequent parses with the same file.

The results produced by this program should never be accepted as true performance measurements.

usage
	java xni.Counter (options) uri ...

options

Option  Description  -p name  Select parser configuration by name.  -x number  Select number of repetitions.  -n | -N  Turn on/off namespace processing.  -np | -NP  Turn on/off namespace prefixes. NOTE: Requires use of -n.   -v | -V  Turn on/off validation.  -s | -S  Turn on/off Schema validation support. NOTE: Not supported by all parser configurations.   -f | -F  Turn on/off Schema full checking. NOTE: Requires use of -s and not supported by all parsers.   -m | -M  Turn on/off memory usage report.  -t | -T  Turn on/off \"tagginess\" report.  --rem text  Output user defined comment before next parse.  -h  Display help screen.

notes

The speed and memory results from this program should NOT be used as the basis of parser performance comparison! Real analytical methods should be used. For better results, perform multiple document parses within the same virtual machine to remove class loading from parse time and memory usage. The "tagginess" measurement gives a rough estimate of the percentage of markup versus content in the XML document. The percent tagginess of a document is equal to the minimum amount of tag characters required for elements, attributes, and processing instructions divided by the total amount of characters (characters, ignorable whitespace, and tag characters) in the document. Not all features are supported by different parser configurations.

Provides a complete trace of XNI document and DTD events for files parsed.

usage
	java xni.DocumentTracer (options) uri ...

options
	Option  Description  -p name  Specify parser configuration by name.  -n | -N  Turn on/off namespace processing.  -v | -V  Turn on/off validation.  -s | -S  Turn on/off Schema validation support. NOTE: Not supported by all parser configurations.   -c | -C  Turn on/off character notifications");  -h  Display help screen.

A sample XNI writer. This sample program illustrates how to take received XMLDocumentHandler callbacks in order to print a document that is parsed.

usage
	java xni.Writer (options) uri ...

options
	Option  Description  -p name  Select parser configuration by name.  -n | -N  Turn on/off namespace processing.  -v | -V  Turn on/off validation.  -s | -S  Turn on/off Schema validation support. NOTE: Not supported by all parser configurations.   -h  Display help screen.

This is an example of a component that converts XNI events for a document into XNI events for that document's PSVI information.

This class can NOT be run as a standalone program. It is only an example of how to write a component. See xni.parser.PSVIConfiguration and xni.parser.PSVIParser.

This sample illustrates how to use Xerces's grammar preparsing functionality to build a compiled representation of a grammar and use it to parse instance documents. It is also meant to replace the DOM ASBuilder sample (which implements the DOM AS interfaces which have been discontinued by W3C). It handles both XML Schema grammars and DTD external subsets.

usage
	java xni.XMLGrammarBuilder [-p config_file] -d uri ... | [-f|-F] -a uri ... [-i uri ...]

options

Option  Description  -p name  Select parser configuration by name.  -d  URI of file(s) to be compiled as DTD external subsets  -a  URI of file(s) to be compiled as XML Schema grammars  -f | -F  Turn on/off Schema full checking when validating instances against schemas. NOTE: Requires use of -a and not supported by all parsers.   -i  List of instance documents to validate. The preparsed grammars will be used first, but if a reference is made to a non-preparsed grammar, it will be resolved.

notes

No two schema grammars preparsed by this class should share the same targetNamespace (or have no targetNamespace). If this condition is not meant, results are undefined--but, very likely, one of the schemas will simply be ignored. Not all features are supported by different parser configurations. Particularly, if a parser configuration is specified, it would be wise to ensure it supports the kind of grammars to be preparsed.

This sample demonstrates how to implement a simple pass-through filter for the document "streaming" information set using XNI. This filter could be used in a pipeline of XNI parser components that communicate document events.

This class can NOT be run as a standalone program. It is only an example of how to write a document handler.

This sample demonstrates how to create a filter for the document "streaming" information set that turns element names into upper case.

This class can NOT be run as a standalone program. It is only an example of how to write a document handler.

Non-validating parser configuration.

This class can NOT be run as a standalone program. It is only an example of how to write a parser configuration using XNI. You can use this parser configuration by specifying the fully qualified class name to all of the XNI samples that accept a parser configuration using the -p option. For example:

	java xni.Counter -p xni.parser.NonValidatingParserConfiguration document.xml

This abstract parser configuration simply helps manage components, features and properties, and other tasks common to all parser configurations. In order to subclass this configuration and use it effectively, the subclass is required to do the following:

• Add all configurable components using the addComponent method,
• Implement the parse method, and
• Call the resetComponents before parsing.

This class can NOT be run as a standalone program. It is only an example of how to write a parser configuration using XNI.

This example is a very simple parser configuration that can parse files with comma-separated values (CSV) to generate XML events. For example, the following CSV document:

	Andy Clark,16 Jan 1973,Cincinnati

produces the following XML "document" as represented by the XNI streaming document information:

	<?xml version='1.0' encoding='UTF-8' standalone='true'?> <!DOCTYPE csv [ <!ELEMENT csv (row)*> <!ELEMENT row (col)*> <!ELEMENT col (#PCDATA)> ]> <csv> <row> <col>Andy Clark</col> <col>16 Jan 1973</col> <col>Cincinnati</col> </row> </csv>

This class can NOT be run as a standalone program. It is only an example of how to write a parser configuration using XNI. You can use this parser configuration by specifying the fully qualified class name to all of the XNI samples that accept a parser configuration using the -p option. For example:

	java xni.Counter -p xni.parser.CSVConfiguration document.xml

This parser class implements a SAX parser that can parse simple comma-separated value (CSV) files.

This class can NOT be run as a standalone program. It is only an example of how to write a parser using XNI. You can use this parser by specifying the fully qualified class name to all of the SAX samples that accept a parser using the -p option. For example:

	java sax.Counter -p xni.parser.CSVParser document.xml

This example is a parser configuration that can includes a post schema validation infoset converter. The configuration includes: DTD validator, Namespace binder, XML Schema validators and PSVIWriter component.

This class can NOT be run as a standalone program. It is only an example of how to write a parser configuration using XNI. You can use this parser configuration by specifying the fully qualified class name to all of the XNI samples that accept a parser configuration using the -p option:

	java xni.Writer -v -s -p xni.parser.PSVIConfiguration personal-schema.xml

Validation and schema validation features must be set to true to receive the correct PSVI output.

This parser class implements a SAX parser that outputs events for the post schema validation infoset of a document.

This class can NOT be run as a standalone program. It is only an example of how to write a parser using XNI. You can use this parser by specifying the fully qualified class name to all of the SAX samples that accept a parser using the -p option. For example:

	java sax.Writer -v -s -p xni.parser.PSVIParser personal-schema.xml

Validation and schema validation features must be set to true to receive the correct PSVI output.

When you create a Xerces parser, either directly using a native class like org.apache.xerces.parsers.DOMParser, or via a standard API like JAXP, Xerces provides a dynamic means of dynamically selecting a "configuration" for that parser. Configurations are the basic mechanism Xerces uses to decide exactly how it will treat an XML document (e.g., whether it needs to know about Schema validation, whether it needs to be cognizant of potential denial-of-service attacks launched via malicious XML documents, etc.) The steps are fourfold:

1. * first, Xerces will examine the system property org.apache.xerces.xni.parser.XMLParserConfiguration;
2. next, it will try and find a file called xerces.properties in the lib subdirectory of your JRE installation;
3. next, it will examine all the jars on your classpath to try and find one with the appropriate entry in its META-INF/services directory.
4. if all else fails, it will use a hardcoded default.

The third step can be quite time-consuming, especially if you have a lot of jars on your classpath and run applications which require the creation of lots of parsers. If you know you're only using applications which require "standard" APIs (that is, don't need some special Xerces property), or you want to try and force applications to use only certain Xerces configurations, then you may wish to copy this file into your JRE's lib directory. We try and ensure that this file contains the currently-recommended default configuration; if you know which configuration you want, you may substitute that class name for what we've provided here.