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
TransformerHandler(the SAX specification says the sequence of events emitted by an
XMLReaderdepends on various configuration settings of the
- 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
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
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
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
There are some minor non-conformances in the Saxon implementation of this interface:
The interface specification restricts the types of
Resultobject that can be supplied to a
Validator. Saxon does not enforce these restrictions, it allows any kind of
Saxon's implementation of
ValidatorHandlerperforms more buffering of events than is permitted by the specification.
TypeInfoProvideralways 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
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.