SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
Conditions of Use
Using XSLT 2.0
Using XQuery
Handling Source Documents
XML Schema Processing
The XPath API
Saxon on .NET
Extensibility
Saxon Extensions
Sample Saxon Applications
The Saxon SQL Extension
XSLT Elements
XPath 2.0 Expression Syntax
Function Library
Standards Conformance
| Introduction
| XSLT 2.0 conformance
| XPath 2.0 conformance
| XQuery 1.0 Conformance
| Conformance with XML Schema 1.0
| Serialization
| Conformance with other specifications
| Character Encodings Supported
» | JAXP 1.3 Conformance

# 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 JDK 1.4.

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 four object models: DOM, JDOM, XOM, and the native Saxon object model. The URIs used to identify these object models are:

- http://java.sun.com/jaxp/xpath/dom

- http://www.jdom.org/provisional

- http://www.xom.nu/jaxp/xpath/xom

- http://saxon.sf.net/jaxp/xpath/om

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 `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. 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 these 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 `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.