XSLT 2.0 conformance

This release of Saxon is a complete implementation of the XSLT 2.0 Recommendation of 23 January 2007, together with all errata published up to 10 April 2009, which are consolidated in the Proposed Edited Recommendation of 21 April 2009.

At user option Saxon also implements parts of the draft XSLT 3.0 specification. The statements in this section apply only if the option to invoke Saxon as an XSLT 3.0 processor is not selected.

Saxon-HE 9.x and Saxon-PE 9.x act as a Basic XSLT Processor, while Saxon-EE 9.x acts as a Schema-Aware XSLT Processor. The distinction is that a Basic XSLT Processor does not allow schemas to be imported and does not support validation of source or result documents or reference to user-defined types. These correspond to the two conformance levels defined in the XSLT 2.0 specification.

The XSLT 2.0 specification defines two optional conformance features, the serialization feature and the backwards compatibility feature. These optional features are implemented in all three Saxon editions.

The following non-conformances apply only on the .NET platform, and only when using the Microsoft System.Xml parser:

Under .NET, when the System.Xml parser is used, attributes declared in the DTD as being of type ID are not accessible using the id() function. This is because the System.Xml parser (XMLValidatingReader) does not make the DTD-defined attribute type available to the application.
Similarly, when the System.Xml parser is used, unparsed entities are not reported to Saxon by the .NET parser, so the calls unparsed-entity-uri() and unparsed-entity-public-id() will always return a zero-length string.

These restrictions do not apply when a JAXP parser is used in place of the Microsoft parser. Since 9.3, the JAXP parser has therefore been the default. Setting the option processor.SetProperty("http://saxon.sf.net/feature/preferJaxpParser", "true") causes Saxon to use the Apache Xerces parser in preference to the (Microsoft) System.Xml parser. Xerces is bundled in the Saxon DLL; this parser is used in preference to the JAXP parser included in the OpenJDK library because it is more reliable and because it has no unnecessary references to other libraries.

Test results

Saxonica has submitted test results for the W3C XSLT Test Suite. At present this test suite, and the submitted results, are available to W3C members only. Saxon's submitted results in the suite (for Saxon 8.8, which was the first version to claim conformance), are available here.

A number of bugs have been raised against the XSLT 2.0 specification which are not yet the subject of published errata. The most significant is Bug 5857, which affects whether or not xmlns="" namespace undeclarations should appear in the result of copy operations. Saxon 9.4 partially implements the proposed fix to this bug.

Checklist of Implementation-Defined Items

The following list describes the way in which Saxon implements the features that the specification leaves implementation-defined. The numbering of items in the list corresponds to the numbering in the checklist provided as Appendix F of the XSLT 2.0 specification.

The way in which an XSLT processor is invoked, and the way in which values are supplied for the source document, starting node, stylesheet parameters, and base output URI, are implementation-defined. (See 2.3 Initiating a Transformation)

Saxon offers a command line interface, and a Java API. The Java API conforms to the JAXP 1.3 Transformation interface defined in the JDK specifications, extended as necessary to support XSLT 2.0 facilities.
The mechanisms for creating new extension instructions and extension functions are implementation-defined. (See 2.7 Extensibility)

The mechanisms offered by Saxon are described in extension instructions and extension functions respectively.
Where the specification provides a choice between signaling a dynamic error or recovering, the decision that is made (but not the recovery action itself) is implementation-defined. (See 2.9 Error Handling)

In most cases Saxon allows the user to make this choice, using the options -w0, -w1, and -w2 on the command line (meaning respectively: ignore the error silently, continue after a warning, treat the error as fatal). Equivalent options are also available in the Java API.

There are some cases where this does not apply:
- XTRE1160 (unrecognized media type): this error is not detected, Saxon always takes the recovery action.
- XTRE1630 (disable-output-escaping when the result is not serialized): this error is not detected, Saxon always takes the recovery action.
It is implementation-defined whether type errors are signaled statically. (See 2.9 Error Handling)

Saxon does extensive type checking at compile time, though it does not follow the precise inference rules as defined in the W3C Formal Semantics. Errors are signaled statically only where a construct cannot possibly succeed (that is, where it will always fail with a type error at run-time if evaluated). Warnings are signaled (a) where a path expression will always return an empty sequence (for example, @x/@y), and (b) in the case of a construct that can only succeed if the supplied value is an empty sequence, for example when comparing values whose statically-inferred types are integer? and string? respectively.
The handling of serialization errors is implementation-defined. (See 2.9 Error Handling)

Saxon reports all serialization errors defined in the serialization specification, and treats them as fatal unless the serialization specification itself defines them as recoverable, in which case they are handled as warnings.
The set of namespaces that are specially recognized by the implementation (for example, for user-defined data elements, and extension attributes) is implementation-defined. (See 3.6.2 User-defined Data Elements)

The only namespace that is specially recognized is http://saxon.sf.net/.
The effect of user-defined data elements whose name is in a namespace recognized by the implementation is implementation-defined. (See 3.6.2 User-defined Data Elements)

The user-defined data elements recognized by Saxon (for example, saxon:collation, saxon:import-query, and saxon:script) are described in extension instructions. Any other element in the Saxon namespace is signaled as an error.
It is implementation-defined whether an XSLT 2.0 processor supports backwards-compatible behavior. (See 3.8 Backwards-Compatible Processing)

Saxon supports backwards-compatible behavior.
It is implementation-defined what forms of URI reference are acceptable in the href attribute of the xsl:include and xsl:import elements, for example, the URI schemes that may be used, the forms of fragment identifier that may be used, and the media types that are supported. (See 3.10.1 Locating Stylesheet Modules)

Saxon allows a user-specified URIResolver to handle these URIs, in which case the forms of URI that are accepted depend on this URIResolver. By default, Saxon on the Java platform uses the mechanisms in the java.net.URI class of the underlying Java VM, while on the .NET platform the capabilities of the System.Uri class are used. The capabilities of these underlying classes depend on the version and variant of the platform in use, and may also be customized by users.

Saxon places no restriction on the media type of a stylesheet module. Regardless of the media type, it accepts a "bare name" fragment identifier as a reference to an element within the retrieved document, identified by an attribute of type ID.
An implementation may define mechanisms, above and beyond xsl:import-schema, that allow schema components such as type definitions to be made available within a stylesheet. (See 3.13 Built-in Types)

In addition to importing types using xsl:import-schema, Saxon implicitly imports a type corresponding to each class that is present in the Java classpath. These types have names in the namespace http://saxon.sf.net/java-type; the local name of the type is the same as the full name of the Java class (for example, java.net.URI), with any "$" signs replaced by hyphens. These types are intended for use with extension functions written in Java.
It is implementation-defined which versions of XML and XML Namespaces (1.0 or 1.1) are supported. (See 4.1 XML Versions)

Saxon gives the user the choice. See Saxon and XML 1.1.
The implicit timezone for a transformation is implementation-defined. (See 5.4.3.2 Other components of the XPath Dynamic Context)

Saxon uses the timezone obtained from the system clock, unless the user specifies a different timezone as a run-time option.
The numbering sequences supported by the xsl:number instructions, beyond those defined in this specification, are implementation-defined. (See 12.3 Number to String Conversion Attributes)

Saxon allows localized numbering sequences to be defined by user-written plug-in code: see implementing localized numbers. In the absence of such a plug-in, the sequences that are supported are those defined in the specification, plus Greek upper-case (x0391), Greek lower-case (x03b1), Cyrillic upper case (x0410), Cyrillic lower-case (x0430), Hebrew (x05d0), Hiragana A (x3042), Katakana A (x30a2), Hiragana I (x3044), Katakana I (x30a4), and Kanji digits (x4e00). If an unrecognized letter is used as a formatting token, Saxon constructs a sequence starting with that letter and making use of the contiguous Unicode code-points starting with that letter that are classified as letters or digits. For example, the format token "x" produces the sequence x, y, z, xx, xy, xz, ...
There may be implementation-defined upper bounds on the numbers that can be formatted by xsl:number using any particular numbering sequence. (See 12.3 Number to String Conversion Attributes)

Saxon imposes no limits on numbering sequences using letters or digits (other than those imposed by resource limitations). Roman numerals are handled in the range 1 to 9999, though values above 4000 are best avoided because there are no recognized conventions.
The set of languages for which numbering is supported by xsl:number, and the method of choosing a default language, are implementation-defined. (See 12.3 Number to String Conversion Attributes)

The default language is English. Localizations for number and date formatting are available for Belgian French, Danish, Dutch, English, French, Flemish, German, Italian, and Swedish. Other languages are supported only if user-written (or third-party) localization plug-ins are provided.
If the data-type attribute of the xsl:sort element has a value other than text or number, the effect is implementation-defined. (See 13.1.2 Comparing Sort Key Values)

Any value other than text or number is treated as an error.
The facilities for defining collations and allocating URIs to identify them are implementation-defined. (See 13.1.3 Sorting Using Collations)

Saxon allows a user-written CollationURIResolver to interpret the collation URI, in which case there are no restrictions on the URI that is used. If the standard CollationURIResolver is used, two forms of URI are recognized: a URI declared using the saxon:collation element in the stylesheet, and a URI of the form http://saxon.sf.net/collation?keyword=value;keyword=value;... as described in Collation. It is also possible to register collations (with user-defined names) via the Java API.
The algorithm used by xsl:sort to locate a collation, given the values of the lang and case-order attributes, is implementation-defined. (See 13.1.3 Sorting Using Collations)

Given the lang attribute, Saxon on the Java platform uses the Java Locale mechanisms to find a locale for that language, and hence a collation. On the .NET platform, Saxon similarly finds a collation appropriate to the .NET culture for that language. Given the case-order attribute, Saxon takes the collation that would be used in the absence of this attribute, changes its strength to secondary (making it case-blind), and then re-evaluates the result of any comparison performed by the base collator so that if the base collator decides two strings are equal, they are examined again to establish the effect of any case differences.
The set of media types recognized by the processor, for the purpose of interpreting fragment identifiers in URI references passed to the document function, is implementation-defined. (See 16.1 Multiple Source Documents)

Saxon ignores the media type entirely. Fragment identifiers are interpreted as bare names (matching ID attribute values) regardless of the media type.
The set of languages, calendars, and countries that are supported in the date formatting functions is implementation-defined. If any of these arguments is omitted or set to an empty sequence, the default is implementation-defined. (See 16.5.2 The Language, Calendar, and Country Arguments)

Saxon allows the localizations for particular languages to be defined as user-written plug-ins. The localizations supported for date/time formatting are the same languages that are supported for numbering (see above). The country argument is ignored except when determining a timezone name: in this case Saxon outputs a time zone name if the timezone is used in the specified country; if the timezone is attached to a date or dateTime then it also takes account of whether that date is known to be in daylight savings time (summer time) in the country in question.
The choice of the names and abbreviations used in any given language for calendar units such as days of the week and months of the year is implementation-defined. (See 16.5.2 The Language, Calendar, and Country Arguments)

For English, the days of the week are Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday. If abbreviations are requested the values used are Mon, Tues, Weds, Thurs, Fri, Sat, Sun, right-truncated if necessary to the requested maximum length. If the minimum length is 1 and the maximum is 2, then the values used are M Tu We Th F Sa Su.

For English, the names of the months are January, February, March, April, May, June, July, August, September, October, November, and December. If abbreviation is requested, the leading part of the name to the required length is used (always returning at least three characters).

The values returned by the system-property function, and the names of the additional properties that are recognized, are implementation-defined. (See 16.6.5 system-property)

The following table shows the values returned for system-defined properties, for Saxon-HE, Saxon-PE, and Saxon-EE: here "9.4.0.1" is replaced by the current version number. The suffix "J" indicates the Java platform; this is replaced by "N" on the .NET platform.

Name	Saxon-HE	Saxon-PE	Saxon-EE	Notes
xsl:version	2.0	2.0	2.0
xsl:vendor	Saxonica	Saxonica	Saxonica	Changed in Saxon 9.4
xsl:vendor-url	http://www.saxonica.com/	http://www.saxonica.com/	http://www.saxonica.com/
xsl:product-name	SAXON	SAXON	SAXON
xsl:product-version	HE 9.4.0.1J	PE 9.4.0.1J	EE 9.4.0.1J	For PE, and EE, if no license file is available then the string "(unlicensed)" is added after the edition code.
xsl:is-schema-aware	no	no	yes or no	depends on whether the particular transformation is schema-aware
xsl:supports-serialization	yes	yes	yes
xsl:supports-backwards-compatibility	yes	yes	yes
xsl:supports-namespace-axis	yes	yes	yes	See Erratum E14 to the specification

If the name of the system property is in the null namespace, Saxon returns the value of the Java system property whose name matches the local name.

The destination and formatting of messages written using the xsl:message instruction are implementation-defined. (See 17 Messages)

By default, messages are formatted as XML and written to the standard error output. Both the formatting and the destination can be customized through the Java API.
The effect of an extension function returning a string containing characters that are not legal in XML is implementation-defined. (See 18.1.2 Calling Extension Functions)

Saxon does not validate the values that are returned. Invalid values may cause an error during subsequent processing, or may be written to the final output destination, resulting in ill-formed XML.
The way in which external objects are represented in the type system is implementation-defined. (See 18.1.3 External Objects)

Saxon represents external objects as a subtype of item. A QName is allocated to such types based on the Java class name of the external object, within the namespace http://saxon.sf.net/java-type. The local name is the same as the expanded Java class name, with "$" replaced by "-".
The way in which a final result tree is delivered to an application is implementation-defined. (See 19 Final Result Trees)

In the case of the principal result tree, the destination is specified using the JAXP API (as the second argument of the transform() method). If secondary result trees are not to be serialized to filestore, a user-written OutputURIResolver must be nominated. Saxon will pass all generated result trees to this class, which can then do what it likes with them.
Implementations may provide additional mechanisms allowing users to define the way in which final result trees are processed. (See 19.1 Creating Final Result Trees)

See previous item.
If serialization is supported, then the location to which a final result tree is serialized is implementation-defined, subject to the constraint that relative URIs used to reference one tree from another remain valid. (See 20 Serialization)

The href attribute of xsl:result-document is interpreted as a relative URI, relative to the URI that defines the destination to which the principal result tree is serialized. This is defined by the -o option on the command line, or by the SystemID of the Result object supplied using the JAXP API.
The default value of the encoding attribute of the xsl:output element is implementation-defined. (See 20 Serialization)

The default encoding is UTF-8.
It is implementation-defined which versions of XML, HTML, and XHTML are supported in the version attribute of the xsl:output declaration. (See 20 Serialization)

For HTML and XHTML, Saxon treats the version attribute as documentary only. For XML, versions 1.0 and 1.1 are recognized.
The default value of the byte-order-mark serialization parameter is implementation-defined in the case of UTF-8 encoding. (See 20 Serialization)

A byte order mark is written only if explicitly requested (that is, the default is "no").
It is implementation-defined whether, and under what circumstances, disabling output escaping is supported. (See 20.2 Disabling Output Escaping)

Disable-output-escaping is supported provided that the final result tree is being written to a StreamResult. It can also be notified to a SAXResult, as described in the JAXP documentation. Disable-output-escaping is not supported when writing to a temporary tree.