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 class `SequenceValue` has disappeared; all its functionality has been moved up into the `Value` class. This reflects the reality that every value in the XPath data model is a sequence. (If there is a special case, it is the singleton value, not the sequence. However, I decided not to add a `SingletonValue` class, since we already have `SingletonNode` and `AtomicValue` which do the job between them.)

This may cause some side-effects on the detailed rules for binding of Java extension functions. In the past some distinctions were made depending on whether the supplied value of an argument was or was not a `SequenceValue`.

A new class `ValueRepresentation` has been introduced. This represents the union of `Value` and `NodeInfo`. In many places where previously a `Value` was expected, the software can now handle a `NodeInfo` as well: notably when setting or getting the value of a variable. The greatly reduces the need to wrap a `NodeInfo` within a `SingletonNode` whenever there is a need to use it as a value.

When an expression is evaluated lazily, the Closure that contains all the information needed to evaluate it no longer contains copies of local variables if the expression does not use any local variables (which is true most of the time). As well as avoiding the small cost of doing the copying, this has the more significant benefit that it avoids creating unnecessary long-lasting references to the objects representing the variables, which means they can be garbage-collected sooner.

The `PipelineConfiguration` object now includes, where appropriate, a reference to the `Controller`. This makes much more context information available to a user-written serializer. The code for creating a `CharacterMapExpander` has been moved into a new method in the `Controller`, allowing user-written serializers to expand character maps if they wish to do so.

The `convert` method (or set of methods) on `AtomicValue` has been changed. Conversion to a built-in type is now handled using the `convertPrimitive` method. These and similar methods (such as `validateContent`) now return an `ErrorValue` rather than throwing an exception when the conversion fails: this is designed to improve performance on paths where failures are normal, such as when validating a union type. There is also an option to perform the conversion without validation, which is especially useful when obtaining the typed value of a node that is known to be valid (Saxon does not store the typed value, but computes it from the string value each time it is needed.)

The implementation of several of the XPath axes against a XOM object model has been rewritten (for improved performance) by Wolfgang Hoschek.

Next