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 atomic type constants (such as `Type.STRING_TYPE`) in class `Type` have been removed. They have been replaced with constants (such as `BuiltInAtomicType.STRING` in class `BuiltInAtomicType`.

The class `Value` no longer implements `Expression`. Instead, an expression that evaluates to constant value is now represented by a `Literal` that encapsulates the `Value`. This simplifies the implementation of `Value` and all its subclasses, and it also means that all the objects on an expression tree can now contain location information and parent pointers, simplifying the manipulation of the tree. As a consequence of this change, it has been possible to merge the class `ComputedExpression` and the interface `Expression` into a single abstract class.

The hierarchy of `SequenceIterator` classes and interfaces has been changed. The interface `AxisIterator` (which is returned by `NodeInfo.iterateAxis()`) is now reserved for iterators that return nodes only. Several new methods are defined in this interface, designed to allow implementations that return "wrapper" nodes to defer the construction of the wrapper until it is actually needed. Default implementations of these methods can be copied from the class `net.sf.saxon.om.AxisIteratorImpl`.

The concept of an atomizable iterator no longer exists: this was a previous attempt to allow construction of nodes to be avoided when not required, and is superseded by the new mechanism. A client can now call the `atomize()` method on the `AxisIterator` itself, to avoid materializing the node when only its atomized value is required.

There has been some reorganization of the classes used to represent collations. Previously the general-purpose `Comparator` class was widely used, which led to confusion as to which kind of `Comparator` was needed in different places. The code now distinguishes two kinds of comparator: a `StringCollator`, which represents a collation in the XPath sense and is used specifically to compare strings, and an `AtomicComparer`, which is used to compare arbitrary atomic values (and which may encapsulate a `StringCollator` when string comparison using a collation is called for). This change affects some user-visible interfaces, for example the `CollationURIResolver`.

The class `NamedCollation` (an implementation of `StringCollator`) has been introduced to represent a collation other than the default collation. It encapsulates a collation URI and the `StringCollator` object used to perform the actual comparison. The URI is retained so that the `NamedCollation` can be reconstructed, for example when compiled code is executed.

The code for arithmetic expressions has been extensively reorganized. All arithmetic expressions are now represented on the expression tree by one of two classes: `ArithmeticExpression` or `ArithmeticExpression10`, the latter being used only when backwards compatibility mode is in force. The `ArithmeticExpression` object contains a reference to a `Calculator` object, which is not itself an expression, but is a helper object that actually performs the computation. There are many different subclasses of `Calculator` for different operators and combinations of operands. If the types of the operands are known early, then a specific `Calculator` can be allocated at compile time; if not, a generic `Calculator` is used which examines the dynamic types of the operands at run-time and invokes one of the specific `Calculator`s accordingly. This reorganization should give a slight speed-up to interpreted code, especially where static types can be inferred, but the main purpose is to enable the Java code generator to do a good job in translating XPath arithmetic expressions to Java.

When the API for free-standing XPath expressions is used, an `Executable` object is now created, which makes it possible to use extension functions such as `saxon:evaluate()` that rely on the presence of an `Executable`.

When running XQuery with a non-schema-aware Configuration, the default construction mode in the static context has changed from "preserve" to "strip". In this situation, the input nodes will normally be untyped, and this choice ensures that if new document is constructed by the query, the output nodes will also be untyped.

There has been some reorganization of the classes used to represent atomic values, designed to bring the Java class hierarchy into closer alignment with the XPath type hierarchy:

- The class `DerivedAtomicValue`, used for values belonging to a user-defined atomic type, is no longer used; instead, the relevant primitive type is used, for example `StringValue` or `DoubleValue`. The root `AtomicValue` class now contains a field giving the type label so that subtypes can be distinguished. In consequence, the method `getPrimitiveValue()` is no longer required, and has been removed.

- The class `RestrictedStringValue` has been removed; strings belonging to subtypes of `xs:string` (for example, `xs:NCName`) are now instances of `StringValue`.

- All integers now belong to the abstract class `IntegerValue`, which has two concrete implementation classes, `Int64Value` and `BigIntegerValue`.

- `NotationValue` no longer inherits from `QNameValue`, instead both share a common abstract superclass, `QualifiedNameValue`.

- The classes `GYearValue`, `GYearMonthValue`, `GMonthValue`, `GMonthDayValue`, and `GDayValue` no longer inherit from `DateValue`. Instead they now share an abstract superclass `GDateValue` which contains the shared code.

These changes mean that in most cases it is now possible to use Java tests such as `x instanceof DateTimeValue` to test whether an `AtomicValue` is an instance of `xs:dateTime` or one of its subtypes. There are still one or two exceptions to this, however: `IntegerValue` in the Java class hierarchy is not a subclass of `DecimalValue`, while `UntypedAtomicValue` and `AnyURIValue` are both implemented as subclasses of `StringValue`. It should also be noted that an atomic value is not necessarily represented by an instance of the `AtomicValue` class: it might also on occasions be represented, say, by a `SequenceExtent` of length one, or by a `MemoClosure`. Before relying on the representation, the method `Value.reduce()` should be used to simplify such representations.

Next