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.