JAXP Conformance

Saxon on the Java platform implements the JAXP 1.3 API, and selected features of later versions. Since JDK 1.5 the JAXP API has been available as a standard part of the Java platform, and it provides access to XSLT transformation, schema validation, and XPath processing services.

The JAR files for Saxon-HE, Saxon-PE, and Saxon-EE contain in their manifests the service provider configuration files needed to identify Saxon as an XSLT processor, and Saxon-EE contains the manifest to identify itself as an XSD schema processor. This means that if Saxon is on the classpath, applications using the JAXP service discovery API may pick up Saxon as the XSLT or Schema processor whether this is explicitly requested or not. Saxon no longer identifies itself as an XPath provider. This is because applications using the JAXP API to request an XPath processor have often not been validated with Saxon, and can fail as a result (for example, because they are expecting an XPath 1.0 processor rather than a 2.0 processor). Applications wanting to use Saxon as their XPath provider must therefore request it explicitly.

Saxon implements the interfaces in the javax.xml.transform package in full, including support for SAX, DOM, and Stream input, and SAX, DOM, and Stream output.

It should be noted that there are many points of detail where JAXP is under-specified. Some of these areas include:

• The types of values that can be supplied as transformation parameters.
• The exact sequence of SAX events that can be supplied to a TemplatesHandler or TransformerHandler (the SAX specification says the sequence of events emitted by an XMLReader depends on various configuration settings of the XMLReader).
• The extent to which the information passed across the API is validated (for example, whether names of elements and attributes are checked for conformity to the XML naming rules).

In such areas, the Javadoc for the Saxon implementation of JAXP interfaces supplies additional information about Saxon's interpretation of the JAXP specification.

Saxon implements the XPath API (the interfaces in the javax.xml.xpath package) in full. Note however that the XPathException exception used throughout Saxon is unrelated to the class of the same name defined in the XPath API. The Saxon XPath API works with several object models: DOM, JDOM, XOM, DOM4J, Axiom, and the native Saxon object model.

The JAXP 1.3 XPath API is designed primarily for use with XPath 1.0. Saxon implements it with XPath 2.0 and XPath 3.1. This means that decisions were necessary on how to handle the richer set of return types available with 2.0. If the return type requested is String, Number, or Boolean, then Saxon converts the result to one of these types as if by using the XPath functions string(), number(), or boolean(). Items after the first in the atomized sequence are discarded. If the return type requested is NODE, Saxon returns the first item in the result sequence if it is a node, and reports an error if it is an atomic value. If the result sequence is empty, it returns null. If the return type requested is NODELIST, Saxon returns a Java List containing all the items in the sequence, whether they are nodes or not, except in the case where the result consists of DOM Nodes, in which case a DOM NodeList is returned. Nodes are returned using the native node object in the input data model; atomic values are returned using the most appropriate Java class. Note that in the case of numeric results, it is not always easy to predict whether the result will be a Long, a Double, or a BigDecimal, and it is advisable to cast the data to one of the numeric types within the XPath expression to make the result predictable.

Saxon-EE also implements the JAXP 1.3 Validation API. This allows a schema to be parsed and validated, and provides two mechanisms for validating a document against a schema: the Validator and the ValidatorHandler.

There are some minor non-conformances in the Saxon implementation of this interface:

• The interface specification restricts the types of Source and Result object that can be supplied to a Validator. Saxon does not enforce these restrictions, it allows any kind of Source and Result that a Transformer would accept.

• Saxon's implementation of ValidatorHandler performs more buffering of events than is permitted by the specification.

• The method isSpecified(int) in the TypeInfoProvider always returns true.

In addition, Saxon implements part of the javax.xml.parsers API. Saxon no longer provides its own SAX parser, however it does provide a DocumentBuilder. The DOM interfaces are limited by the capabilities of the Saxon DOM, specifically the fact that it is read-only. Nevertheless, the DocumentBuilder may be used to construct a Saxon tree, or to obtain an empty Document node which can be supplied in a DOMResult to hold the result of a transformation.