SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
» | Version 9.1 (2008-07-02)
| Version 9.0 (2007-11-03)
Notices
Using XSLT 2.0
Using XQuery
Handling Source Documents
XML Schema Processing
XPath API for Java
Saxon on .NET
Extensibility
Saxon Extensions
Sample Saxon Applications
The Saxon SQL Extension
XSLT Elements
XPath 2.0 Expression Syntax
Function Library
Standards Conformance

# JAXP

Saxon now supports the `nextSibling` property of a `DOMResult`, introduced in JDK 1.5. This property allows you to specify more precisely the insertion point for new data into an existing DOM tree.

All `TransformerFactory` features that accept a `Boolean` value now also accept the string values "true" and "false". This is useful when the value is set from a configuration file that only permits strings to appear. Many properties that expect the value to be a user-written callback now have an alternative that allows the class name to be supplied as a string, rather than supplying the instance itself. Other properties that expected a symbolic constant have been supplemented by a method that accepts a string. This change also affects the underlying methods in the `Configuration` class.

In Saxon's implementation of the JAXP `Validator` and `ValidatorHandler` interfaces, validation errors (failure of an instance to conform to a schema) are now reported using the `error()` method of the `ErrorListener`, rather than the `fatalError()` method as previously. This means it is normally possible to report more than one error during a single run. Although JAXP does not specify this behavior explicitly, it brings Saxon into line with the reference implementation. (However, one difference with the reference implementation remains: at the end of the validation run, Saxon throws an exception if any validation errors have been reported, whereas Xerces exits as if validation were successful.)

The Configuration property `FeatureKeys.STRIP_WHITESPACE` now affects the result of an `IdentityTransformerHandler`. Previously the setting `ignorable` affected the result, but the setting `all` did not.

A new kind of `Source` is available, the `EventSource`. This represents a source of `Receiver` events, in much the same way as a `SAXSource` represents a source of SAX events; except that it is the `EventSource` itself that supplies the events, not some parser contained in the Source object. This is an abstract class that can be subclassed by user applications; it defines a method `send(Receiver out)` that is called to generate the Receiver events. The particular use case motivating the introduction of this class was a streaming transformation where the input was programmatically generated by the application; this was achieved by having the `URIResolver` return an `EventSource` to generate the events, which the streaming transformation then filtered. Generating `Receiver` events directly proved to be 10-20% faster than generating SAX events.

Next