SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
| Version 8.9 (2007-02-12)
| Version 8.8 (2006-09-05)
| Version 8.7.3 (2006-06-13)
| Version 8.7.2 (2006-04-19)
| Version 8.7.1 (2006-04-13)
| Version 8.7 (2006-02-24)
| Version 8.6.1 (24 November 2005)
| Version 8.6 (3 November 2005)
| Version 8.5.1 (26 August 2005)
| Version 8.5 (2 August 2005)
| Version 8.4 (4 April 2005)
| Version 8.3 (11 February 2005)
» | Version 8.2 (21 December 2004)
| Version 8.1.1 (8 October 2004)
| Version 8.1 (24 September 2004)
| Version 8.0 (1 June 2004)
Conditions of Use
Using XSLT 2.0
Using XQuery
Handling Source Documents
XML Schema Processing
XPath API for Java
Saxon on .NET
Extensibility
Saxon Extensions
Sample Saxon Applications
The Saxon SQL Extension
XSLT Elements
XPath 2.0 Expression Syntax
Function Library
Standards Conformance

# Internal Changes

The `Receiver` interface has been changed: instead of a `Configuration` and a `LocationProvider` being passed down the pipeline, the context information for the pipeline is now passed as a `PipelineConfiguration` object. The provides access to the `Configuration` and the `LocationProvider`, as well as other information: currently an `ErrorListener` and a `URIResolver`. This means that warnings detected by receivers in the pipeline (for example, serialization errors and validation warnings) can now be properly reported to the `ErrorListener` associated with a transformation, rather than with the global `ErrorListener` associated with the `Configuration`. This change was necessary in order to implement the JAXP `Validator` interface (which uses a local `ErrorHandler`), but it has other spin-off benefits. In particular, it means that the information passed down a pipeline can in future be extended by adding new fields to the `PipelineConfiguration` class, with no impact on the `Receiver` interface itself.

User-defined functions are now evaluated lazily (that is, if the function returns a sequence, each item in the sequence is evaluated only when it is needed). This has required some changes to the implementation of tail call optimization. There are now two kinds of Closure: the new `Closure` class is used when the results are needed only once, as when evaluating a function call. The old `Closure` class is renamed `MemoClosure`, and is used when the results are likely to be needed more than once, as when evaluating a variable.

Saxon now does static analysis of variable references to identify variables that are never referenced, and variables that are only referenced once. If a variable is only referenced once, then during lazy evaluation of the variable the value will be discarded rather than being retained in memory for subsequent reference. There are now two classes supporting lazy evaluation: `Closure` is a value that is evaluated when first needed and is immediately discarded from memory, while `MemoClosure` also defers evaluation, but retains each item in the evaluated sequence once it is known. This analysis is currently done only for local variables and function parameters (not for global variables or XSLT template parameters).

The algorithm for type-checking (the XPath function call rules) has been rewritten to follow the specification more precisely. The rules have gradually been refined over successive W3C drafts, and although the changes are very minor, the implementation had got a little out of step.

The optimizer now recognizes that certain expressions cannot be moved out of a loop. A classic example is the XQuery expression `count(./(for $i in 1 to 5 return <a/>))`, which should return 5. Previous Saxon releases moved the element constructor out of the loop, and thus returned the value 1. Similar constructs occur in XSLT in the case of an XPath expression that calls a stylesheet function. At present all calls on user-defined functions (and XSLT templates) are treated as if they might create new nodes. This does not affect expressions that create new nodes in a context where the final result cannot depend on the identity of the new nodes: for example, if a node is created or a function is called within the predicate of a filter expression, this will still be extracted from the loop and evaluated only once.

The same considerations apply to path expressions in which one of the steps constructs new nodes. For example the result of `count(a/<x/>)` should be equal to the number of `a` elements selected; in previous Saxon releases it was always 1.

The TinyTree data structure now allows a single TinyTree to contain any number of trees rooted either at document nodes or element nodes. Allowing multiple parentless element nodes in a single TinyTree reduces the overhead involved in constructing sequences of elements.

Where appropriate, `xsl:copy-of` now creates virtual copies of nodes, using the new class `VirtualCopy`. This is simply a reference to the node that was copied, together with sufficient information to give the copy a different node identity from the original. This technique is used in cases where the copy is not being directly written to another tree, for example where it is returned as the value of a variable or function.

Next