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

# XSLT changes

Some changes have been made to the `format-date()` family of functions:

- Whitespace characters are now removed from a variable marker specified in the picture.

- When displaying fractional seconds, up to six digits of precision may be displayed. The width modifiers for the "f" component are now recognized: for example "f,2-2" displays exactly two decimal places; "f,1-6" displays at least one decimal place and at most six, "f,*-6" displays as many places as are present in the value; "f,3-*" displays at least three, and as many as are necessary.

- Syntax errors in the picture (for example, references to undefined components) are now non-recoverable errors.

- BC dates and the AD/BC suffix (component [E]) are now displayed correctly. (I've had to take a position here on whether to use "BC" or "BCE" ["Before the Common Era"]. I've chosen the former, mainly because I believe it is more widely used, but also as a matter of personal preference.

- The XSLT 2.0 specification does not say what it means by "week number within a month" (component [w]). I have adopted the definition that week 1 in a month is the week containing the first Thursday of the month, and that the days before the start of week 1 are in week zero.

- If a date/time has no timezone, the XSLT format-date/time() functions now display nothing when the timezone is requested. Previously they displayed the implicit timezone.

- If a calendar other than AD or ISO is requested, the result is prefixed with `[Calendar: AD]` as required by the spec. Similarly, the result is prefixed with `[Language: en]` if an unsupported language is requested and English is used as the fallback.

- Timezones are now formatted correctly when the [Z] and [z] components are used in the picture. With [ZN], a timezone name is used; where several names are in use for the timezone, the country argument (the 5th argument) to format-date/time() is taken into account (for example, timezone GMT+1 is displayed as "BST" where the country is "gb", or as "MEZ" where the country is "de"). However, the list of known timezone names is fairly small. The timezone name is always chosen on the assumption that daylight saving is not in effect. Timezone names can be customized in the same way as other localizations are performed, using a subclass of Numberer.

The rules for processing in forwards-compatible mode have been aligned with the changes that first appeared in the XSLT 2.0 draft of 15 September 2005. The main effect of these changes is to remove the rule that static errors (for example in XPath expressions) are not reported if the instruction is not executed. This means that if you want to mark sections of the stylesheet for use under a future version of XSLT, you should use the new compile-time `[xsl]:use-when` construct, rather than relying on forwards compatible processing mode.

In the format-number() function, Saxon now rounds numbers up or down to eliminate spurious non-zero digits, provided that the resulting number is still equal to the original when converted back to a double. For example, this means that a number such as 1E22 is output as 100,000,000,000,000,000,000,000 rather than 99,999,999,999,999,991,611,392. Both these numbers produce 1E22 when converted back to a to double, and the latter number is the one produced by double-to-decimal conversion, because it is the one closest to the true value of the double.

In `xsl:decimal-format`, Saxon now checks that the character specified as the `zero-digit` is indeed classified in Unicode as a digit with numeric value zero. Previously it took this on trust. Note that this means that certain sensible values which were previously allowed are no longer allowed, for example x2080, SUBSCRIPT ZERO.

Using the built-in types that are not allowed by a Basic XSLT Processor (such as `xs:int`, `xs:token`) in Saxon-B now results in a hard error rather than a warning as previously.

In the past, calls on `xsl:result-document` were disallowed whenever calls on extension functions were disabled: the assumption being that the stylesheet is untrusted and therefore should not be allowed to write to file locations using a relative URI. This restriction now applies only for an `xsl:result-document` instruction with an explicit `href` attribute.

The `format` attribute of `xsl:result-document` is now an attribute value template.

Attributes that contain a collation name (specifically the `collation` attribute of `xsl:sort`, `xsl:key`, and `xsl:for-each-group`; the `[xsl:]default-collation` attribute wherever it appears; and the `name` attribute of `saxon:collation`) now require the collation name to be a valid URI. If it is a relative URI then it is resolved against the base URI of the element where it appears.

The restriction that stylesheets cannot be compiled if they contain calls on saxon:evaluate() has been removed.

Conformance documentation has been added: see Conformance.

Next