<?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>
