<?xml version="1.0" encoding="iso-8859-1"?> <?xml-stylesheet href="../../make-menu.xsl" type="text/xsl"?><html> <head> <this-is section="changes" page="intro91" subpage="jaxp91"/> <!-- Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: JAXP</title> <meta name="coverage" content="Worldwide"/> <meta name="copyright" content="Copyright Saxonica Ltd"/> <meta name="title" content="Saxonica: XSLT and XQuery Processing: JAXP"/> <meta name="robots" content="noindex,nofollow"/> <link rel="stylesheet" href="../../saxondocs.css" type="text/css"/> </head> <body class="main"> <h1>JAXP</h1> <p>Saxon now supports the <code>nextSibling</code> property of a <code>DOMResult</code>, introduced in JDK 1.5. This property allows you to specify more precisely the insertion point for new data into an existing DOM tree.</p> <p>All <code>TransformerFactory</code> features that accept a <code>Boolean</code> 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 <code>Configuration</code> class.</p> <p>In Saxon's implementation of the JAXP <code>Validator</code> and <code>ValidatorHandler</code> interfaces, validation errors (failure of an instance to conform to a schema) are now reported using the <code>error()</code> method of the <code>ErrorListener</code>, rather than the <code>fatalError()</code> 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.)</p> <p>The Configuration property <code>FeatureKeys.STRIP_WHITESPACE</code> now affects the result of an <code>IdentityTransformerHandler</code>. Previously the setting <code>ignorable</code> affected the result, but the setting <code>all</code> did not.</p> <p>A new kind of <code>Source</code> is available, the <code>EventSource</code>. This represents a source of <code>Receiver</code> events, in much the same way as a <code>SAXSource</code> represents a source of SAX events; except that it is the <code>EventSource</code> 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 <code>send(Receiver out)</code> 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 <code>URIResolver</code> return an <code>EventSource</code> to generate the events, which the streaming transformation then filtered. Generating <code>Receiver</code> events directly proved to be 10-20% faster than generating SAX events.</p> <table width="100%"> <tr> <td> <p align="right"><a class="nav" href="extensibility91.xml">Next</a></p> </td> </tr> </table> </body> </html>