Internal changes

Receiver interface

I have introduced a new interface, net.sf.saxon.event.Receiver, which is intended to replace the old Emitter interface. This supports setting type annotations on element and attribute nodes: it allows the type information to be carried with the element and attribute events, and also allows various properties to be associated with each event, used for disable-output-escaping and to indicate when validation has already been done so it does not get done twice.

The classes that implement this interface are largely in package net.sf.saxon.event, which replaces the old net.sf.saxon.output package.

The new interface largely replaces the Outputter interface, ending the artificial distinction between the Outputter and the Emitter, which was there historically because events were handled in a different order at the two interfaces.

The "sticky d-o-e" facility is not working in this release: that is, an error is reported when output is written to a temporary tree with disable-output-escaping="yes". The same happens if the final output of the stylesheet is written to a Saxon tree, for example when using a Saxon-created DOMResult, or when using stylesheet chaining. It is possible that "sticky d-o-e" will not be allowed in the final XSLT 2.0 specification, though at present there are open issues concerning this. {outp09, bug17}

The class hierarchy for XPath expressions (net.sf.saxon.expr.Expression) has been simplified. The two abstract classes SingleValueExpression and SequenceExpression have disappeared; their functionality has moved into the parent class, Expression, driven by the static cardinality of the expression as determined by the getCardinality() method. This allows greater re-use of classes such as BinaryExpression. There is potential for many expressions to be implemented as functions, allowing more use of generic code and table-driven static analysis.

The implementation of SequenceExpressions of the form (1,2,3) has changed completely, and is much simpler. They are now handled by breaking them up into a tree of binary expressions, treating "," as a list concatenation operator. {expr53, 54, 55, 86}

The implementation of FilterExpressions has been rewritten and simplified. Two different iterators are now used, a FilterIterator where every value needs to be tested, and a PositionIterator where the value is known statically to be numeric. This greatly simplifies the code. The way in which reverse axes are handled has also been simplified.

I want to move away from run-time expression reduction on filters to doing a static rewrite that pulls non-dependent subexpressions out of the predicate, but this has not yet been done.

The class XPathException is now abstract. There are two concrete subclasses, XPathException.Static and XPathException.Dynamic, used to distinguish static from dynamic errors. (Other subtypes, for example XPathException.TypeError may be introduced in future. A dynamic error that occurs when an XPath expression is evaluated early (at compile time) is now not reported until run-time, and is only reported if the expression is actually evaluated.