# 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