| SAXONICA |
A process has started of identifying all the Java classes and methods that are considered to form Saxon's public API. These classes and methods are identified with the tag "since 8.4" in the JavaDoc. Every effort will be made in the future to avoid gratuitous changes to these interfaces in future releases. However, there is no absolute guarantee of backwards compatibility, given that the W3C language specifications are still subject to change.
The SequenceIterator specification has been tightened-up to define the results returned
by the current() and position() methods before the first item has been read,
and after the next() method has returned null to indicate the end of the sequence. In addition,
it is now specified that further calls on next() should continue to return null: previously this happened for
some iterators, while others threw an exception. Existing implementations of SequenceIterator
have been changed to conform to these tighter rules. There were a number of places in the Saxon code
that relied on the current() function when applied to a SingletonIterator returning
the same result irrespective of the state of the iterator. This is no longer the case: before next()
is called for the first time, and after next() is called for the second time, the current()
method on a SingletonIterator now returns null.
In the XQuery API, the QueryProcessor class, which has been deprecated since Saxon 8.1,
is now withdrawn. All its methods are available on the StaticQueryContext class.
A user-defined StaticQueryContext is no longer modified by Saxon when a query is compiled.
Instead, Saxon makes a copy for its internal use. This means that the same StaticQueryContext
object may now be used to define multiple queries, in series or in parallel threads. A consequence of this
change is that it is no longer possible to obtain information about the query, for example the names of the
functions that it declares, from the original StaticQueryContext. However, the modified
copy of the StaticQueryContext is available via a method on the XQueryExpression
object.
The API for defining extension instructions in XSLT has changed slightly: various methods are now defined
to throw an XPathException rather than a TransformerConfigurationException.
This change was made to enable error codes to be associated with all error conditions: error codes can be
held in an XPathException, but not in a TransformerConfigurationException.
