SAXON home page

Standards Conformance

XSLT and XPath conformance

SAXON XSLT implements the XSLT 1.0 and XPath 1.0 Recommendations from the World Wide Web Consortium, found at http://www.w3.org/TR/1999/REC-xslt-19991116 and http://www.w3.org/TR/1999/REC-xpath-19991116, which are referred to here collectively as "XSLT"

SAXON is 100% conformant to the mandatory requirements of these standards, with the qualifications noted below.

SAXON will automatically convert a result tree fragment to a node-set when required, provided that the version number is set to "1.1" or later. The relevant version number is the version attribute on the xsl:stylesheet element, or the xsl:version attribute on a literal result element, that contains the xsl:variable declaration for the result tree fragment (the place where the variable is declared, not the place where it is used). This is a technical breach of the XSLT 1.0 specification, because an XSLT 1.0 processor is expected to enforce XSLT 1.0 restrictions even when the stylesheet invokes "forwards compatible mode". However, I believe it follows the spirit of the XSLT forwards compatibility rules.

SAXON is dependant on the user-selected XML parser to ensure conformance with the XML 1.0 Recommendation. However, SAXON itself ensures that the source document and stylesheet comply with the XML Namespaces Recommendation.

SAXON implements the <?xml-stylesheet?> processing instruction in a source XML document provided that the pseudo-attribute href is either the URL of a freestanding stylesheet document, or a fragment identifier matching the id attribute of an embedded stylesheet within the same document. Java APIs are available allowing the application to implement more elaborate schemes of stylesheet addressing than this, including the ability to access an embedded stylesheet by means other than the <?xml-stylesheet?> processing instruction.


Limitations

Documentation

The XSLT specification says that the documentation for an implementation should specify which URI schemes are supported. SAXON supports the URI scheme implemented by the Java java.net.URL class. Additionally, SAXON allows the user to nominate a URIResolver class which can be used to implement any URI scheme the user wants.

The XSLT specification says that the documentation for an implementation should specify for which media types fragment identifiers are supported. SAXON does not support fragment identifiers for any media type. However, a user-written URIResolver can support fragment identifiers if it wishes.

The values of the vendor-specific system properties are:

version1.0
vendorSAXON n.n.n from Michael Kay of ICL
vendor-urlhttp://users.iclway.co.uk/mhkay/saxon/index.html

All three values are subject to change in future releases. Users wishing to test whether the processor is SAXON are advised to test whether the vendor system property starts with the string "SAXON".

Extensions

SAXON implements a number of extensions to standard XSLT, following the rules for extension functions and extension elements where appropriate. The extensions are documented in extensions.html. They are all implemented in accordance with the provisions in the standard for extensibility.

Character encodings supported

The following is the list of encodings recognized by the built-in AElfred parser (case-insensitive):

ISO-8859-1, 8859_1, ISO8859_1
US-ASCII, ASCII 
UTF-8, UTF8
ISO-10646-UCS-2, UTF-16, UTF-16BE, UTF-16LE

The encodings available on output are the intersection of:

ascii, us-ascii, utf-8, utf8, iso-8859-1, iso-8859-2
ko18-r, cp1250, windows-1250, cp1251, windows-1251
(again case-insensitive)

with whatever your Java VM supports.

DOM Conformance

SAXON accepts input (both source document and stylesheet) from any standards-compliant DOM implementation.

SAXON allows the result tree to be attached to any Document or Element node of an existing DOM. Any DOM implementation can be used, provided it is mutable.

SAXON's internal tree structure (which is visible through the Java API, including the case where Java extensions functions are called from XPath expressions) conforms with the minimal requirements of the DOM level 2 core Java language binding. This DOM interface is read-only, so all attempts to call updating methods throw an appropriate DOM exception. No optional features are implemented.

If an extension function returns a DOM Node or NodeList, this must consist only of Nodes in a tree constructed using Saxon. Since Saxon's trees cannot be updated using DOM methods, this means that the nodes returned must either be nodes from the original source tree, or nodes from a tree constructed using Saxon's proprietary API.

TrAX Conformance

The TrAX interface is not yet stable, but Saxon incudes a partial implementation of the interface in its current form for experimental use.

To avoid any confusion as TrAX evolves, I have used the interim package names com.icl.saxon.trax and com.icl.saxon.trax.serialize. The interface definitions are based on TrAX version 0.6, but with some changes which I have proposed for inclusion in a future version of TrAX.

TrAX features not yet implemented include:

Saxon acts as a TrAX Processor, but it does not currently provide a TrAX Serializer, nor does it work with third-party TrAX Serializers.

Error recovery policy

Where the XSLT specification requires that an error be signaled, Saxon produces an error message and terminates stylesheet execution.

Where the XSLT specification states that the processor may recover from an error, Saxon takes one of three actions as described in the table below. Either it signals the error and terminates execution, or it recovers silently from the error in the manner permitted by the specification, or it places the action under user control. In the latter case there are three options: report the error and terminate, recover silently, or (the default) recover after writing a warning to the system error output stream.

Handling of individual recoverable errors is described in the table below.

ErrorAction
There is more than one template rule that matches a node, with the same import precedence and priority User option
There is more that one xsl:namespace-alias statement for a given prefix, with the same import precedence Recover silently
An element name defined using xsl:element is invalid User option
An attribute name defined using xsl:attribute is invalid User option
There are several attribute sets with the same import precedence that define the same named attribute Recover silently
A processing-instruction name defined using xsl:processing-instruction is invalid User option
A node other than a text node is written to the result tree while instantiating xsl:attribute, xsl:comment, or xsl:processing-instruction Recover silently
Invalid characters are written to the content of a comment or processing instruction User option
An attribute node or namespace node is written directly to the root of a result tree fragment Signal the error
The document() function identifies a resource that cannot be retrieved User option
There are several xsl:output elements specifying the same attribute with the same import precedence Recover silently
disable-output-escaping is used for a text node while instantiating xsl:attribute, xsl:comment, or xsl:processing-instruction Recover silently
disable-output-escaping is used for a text node within a result tree fragment that is subsequently converted to a string or number Recover silently
disable-output-escaping is used for a text node containing a character that cannot be output using the target encoding Signal the error

Michael H. Kay
17 November 2000