SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
| Version 8.6.1 (24 November 2005)
| Version 8.6 (3 November 2005)
| Version 8.5.1 (26 August 2005)
| Version 8.5 (2 August 2005)
| Version 8.4 (4 April 2005)
» | Version 8.3 (11 February 2005)
| Version 8.2 (21 December 2004)
| Version 8.1.1 (8 October 2004)
| Version 8.1 (24 September 2004)
| Version 8.0 (1 June 2004)
Conditions of Use
Using XSLT 2.0
Using XQuery
Handling Source Documents
XML Schema Processing
The XPath API
Standards Conformance
Extensibility
Saxon Extensions
Sample Saxon Applications
The Saxon SQL Extension
XSLT Elements
XPath 2.0 Expression Syntax
Function Library
XSLT Patterns

# DOM Level 3 support

Saxon 8.2 introduced support for JAXP 1.3 and DOM Level 3. Unfortunately this caused complications in the installation procedure, because these specifications are not supported "out of the box" with Java JDK 1.4. Saxon 8.3 includes various changes designed to remove these problems. This section describes the changes to DOM support; the next section describes changes to the XPath API.

Saxon 8.3 introduces significant changes in the way that DOM interfaces are supported.

The two implementations of the Saxon object model, Tree and TinyTree, no longer implement DOM interfaces. This change is made for two reasons: firstly, there are incompatibilities between the DOM interface in JDK 1.4 and JDK 1.5 that make it impossible to support both with the same code, and secondly, the ever-increasing complexity of the DOM interface burdens the Saxon implementation without adding anything useful for most users.

So the `NodeInfo` implementations in these two tree models no longer implement `org.w3.dom.Node` and its subclasses. Instead, it is possible to wrap a Saxon `NodeInfo` object in a new class, `NodeOverNodeInfo`, which adds the DOM methods. When a Saxon node is supplied to an extension function that expects a DOM Node or NodeList, Saxon performs this wrapping automatically. This actually means that it is now possible to supply any kind of Saxon node to an extension function that expects a DOM Node - previously not all Saxon nodes implemented the DOM Node interface (for example some parentless nodes, or text nodes in some temporary trees, or nodes that wrap JDOM or XOM nodes).

Because the Saxon tree implementations no longer implement the DOM, the JAXP factory class `net.sf.saxon.om.DocumentBuilderFactoryImpl` is no longer available. In addition, it is no longer possible to use the JAXP `DOMSource` class to supply a Saxon tree as a source or result for a transformation. Instead, you can supply a `NodeInfo` directly as a `Source`, or a `TreeBuilder` or `TinyBuilder` as a `Result`. There are examples in `TraxExamples.java` that show how to do this.

Saxon still supports `DOMSource` and `DOMResult` as the source or result of a transformation. However, they must now encapsulate a third-party DOM Node. They are not used when transforming to or from Saxon trees.

All modules in Saxon that are concerned with DOM support have been moved out of the main JAR file into `saxon-dom.jar`, which need not be on the classpath if DOM interfaces are not required. There are now no references to DOM interfaces in the main body of Saxon code. DOM therefore has exactly the same status as other external object models, for example JDOM and XOM. In fact, it is now possible to register a support module for an additional external object model with the Saxon `Configuration`, so object models are now completely pluggable.

If DOM interfaces are needed, then the classpath should contain both `saxon-dom.jar` and the DOM level 3 classes. The DOM level 3 classes are a standard part of JDK 1.5, but under JDK 1.4 they must be installed separately, as part of the JAXP 1.3 package. The requisite JAR file is simply called `dom.jar`.

The `SchemaType` interface in Saxon no longer implements the DOM `TypeInfo` interface. Instead, a `TypeInfo` can be now be obtained by wrapping a `SchemaType` in a `TypeInfoImpl`.

Similarly, Saxon no longer provides native support for the DOM `LSResourceResolver` interface. In places where it is needed, for example in the validation API, an `LSResourceResolver` can be packaged inside a `URIResourceResolver`, which makes it look like a standard JAXP `URIResolver`. The Saxon `Configuration` and `PipelineConfiguration` now allow only a `URIResolver` to be registered directly, but the validation APIs get round this by registering a `URIResourceResolver` that wraps the `LSResourceResolver`.

A method `getPrefix()` has been added to `NodeInfo`. This method was previously available on nodes that implemented the DOM `Node` interface, but not on other nodes.

The net effect of these changes is:

- To run XQuery or XSLT, the only JAR file you need on the classpath is saxon8.jar, and this will run under either JDK 1.4 or JDK 1.5.

- If you use the XPath API defined in JAXP 1.3, you will also need saxon8-xpath.jar on the classpath. If you use this with JDK 1.4, you will also need to download the JAXP 1.3 component from Sun, and place the jaxp-api.jar JAR file on your classpath.

- If you use DOM level 3 interfaces under JAXP 1.3, you will also need the dom.jar file from the JAXP 1.3 distribution on your classpath.

- If you recompile Saxon, it is easiest to do so under JDK 1.5; but you can recompile under JDK 1.4 if all the necessary JAXP components are present.

Next