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.
