SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
| 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
The XPath API
Saxon on .NET
Extensibility
Saxon Extensions
Sample Saxon Applications
The Saxon SQL Extension
XSLT Elements
XPath 2.0 Expression Syntax
Function Library
Standards Conformance

# XSLT changes

There was a restriction that the characters used for digits and other symbols in `xsl:decimal-format` and in the `format-number` function must be Unicode BMP characters (that is, codepoints above 65535 were not allowed). This restriction has been removed. This means, for example, that you can now format numbers using Osmanya digits.

As a consequence of this change, the old version of the `format-number()` implementation, which relied on Java decimal formatting and was retained under the name `format-number-1.0`, is no longer available.

The output of `xsl:number` has been changed, reflecting a discussion on the xsl-list about the correct interpretation of the specification (which in this respect is unchanged from XSLT 1.0). It appears that when formatting the number sequence (1 to 4) using the format token `[1]`, the correct output is `[1.2.3.4]`, whereas Saxon (in all previous releases including 6.5.x) was outputting `[1[2[3[4]`. The distinction hinges on the interpretation of the term "separator token" in the specification.

The documentation for previous releases described a restriction: "If `key()` is called in a match pattern, the argument must be a string literal." This restriction was in fact removed many releases ago.

Error XTSE1560 is now reported. A static error is reported if there are two conflicting `xsl:output` declarations.

A number of changes have been made to the `unparsed-text()` function:

- The function now reports an error if the content of the file contains characters that are not valid in XML.

- The version of the function with a single argument is available. The encoding is inferred first by looking the HTTP headers if available; then by examining the file to see if it starts with a byte order mark or an XML declaration. If neither strategy succeeds, UTF-8 is assumed.

- If the encoding is UTF-8 and the file starts with a byte order mark, this is not included in the string returned as the result of the function.

- The `unparsed-text-available()` function is implemented (both forms, with one argument or two arguments). However, note that the current implementation is not efficient: if a call on `unparsed-text-available()` is followed by a call on `unparsed-text()` to read the file, the file is actually read twice.

- UTF-16 little-endian encoding, when signalled by a byte-order-mark, is now handled correctly.

It is no longer an error to disable output escaping while writing a temporary tree. Instead, the request to disable output escaping is simply ignored.

An error is now reported when no value is supplied for a required stylesheet parameter, even if the parameter is never referenced. Previously an error was reported only when the parameter was actually referenced.

Minor changes have been made to the way that namespace prefixes are allocated to constructed elements and attributes in cases where a prefix needs to be invented. As required by the specification, in the event of a conflict the prefix of a namespace node that is explicitly attached to an element takes precedence over the prefix used in the `name` attribute of the `xsl:element` instruction.

In general it is no longer an error to use a relative URI in the `href` attribute of `xsl:result-document` when no base URI is known for the principal output file. Instead, the relative URI is interpreted as being relative to the current working directory in the calling environment. However, the error is retained if the configuration option to disallow extension function calls is set: this option indicates that the stylesheet is not trusted to access external resources, and it must therefore not be trusted to write files relative to the current directory.

When a stylesheet selects forwards-compatible mode (that is, when the `version` attribute is greater than 2.0), unrecognized top-level elements are now ignored together with all their content, as required by the specification. Previously errors were reported if such elements contained XSLT instructions with invalid attributes or content.

The extension attribute `saxon:explain="yes"` now causes display of the optimized expression tree for the entire template or function in which it appears, not only for XPath expressions appearing on that specific element. This change has been made because optimization is now carried out on the template or function as a whole.

Next