Saxonica.com

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:

Next