JAXP interface (transformation, XPath, schema processing)

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.