JAXP 1.3 Conformance
Saxon on the Java platform implements the JAXP 1.3 API. This is available as
a standard part of JDK 1.5 (also known as J2SE SDK 5.0), and is available as an optional package for use with
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.
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 five object models: DOM,
JDOM, XOM, DOM4J, and the native Saxon object model. The URIs used to identify these object models are:
The JAXP 1.3 XPath API is designed primarily for use with XPath 1.0. Saxon implements it with
XPath 2.0. 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
boolean(). Items after the first in the atomized sequence are discarded. If the return type
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.
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-SA 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
There are some minor non-conformances in the Saxon implementation of this interface:
The interface specification restricts the types of
object that can be supplied to a
Validator. Saxon does not enforce these restrictions, it
allows any kind of
Result that a
Saxon's implementation of
ValidatorHandler performs more buffering of events than
is permitted by the specification.
isSpecified(int) in the
TypeInfoProvider always returns true.
In addition, Saxon implements part of the
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