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. It also implements certain facilities defined in the draft XSLT 1.1 specification, even where the XSLT 1.0 specification says that these should be rejected as errors.

SAXON will automatically convert a result tree fragment to a node-set when required, as defined in the draft XSLT 1.1 specification.

SAXON supports the <xsl:document> element defined in the draft XSLT 1.1 specification. The implementation is not yet complete: in particular (a) the href attribute is interpreted as a filename relative to the current directory (not the base URI), and (b) the provisions relating to use of while the current output destination is a temporary tree are not yet implemented.

SAXON supports the use of xsl:script to define external Java functions. The archive attribute is available only with a JDK1.2 or later JVM. The rules for identifying a Java class are as defined in XSLT 1.1, but the rules for identifying a method within that class have not yet been brought into line with the new standard (in particular, polymorphic methods are not supported). The Context object now implements the XSLT-defined XSLTContext interface.

SAXON supports the use of xml:base to define the Base URI of a node, as defined in the XSLT 1.1 specifications, except in the case of the base URI of a processing instructions contained in an external entity.

SAXON is dependant on the user-selected XML parser to ensure conformance with the XML 1.0 Recommendation and hte XML Namespaces Recommendation.

SAXON implements the <?xml-stylesheet?> processing instruction as described in the W3C Recommendation Associating StyleSheets with XML Documents. The href pseudo-attribute must be a URI identifying an XML document containing a stylesheet, or a URI with a fragment identifier identifying an embedded stylesheet. The fragment must be the value of an ID attribute declared as such in the DTD.

Limitations

• <xsl:number> is not supported on attribute or namespace nodes.

• Comment nodes in the input document can be processed only if SAX2-compliant parser is used. If a SAX1 parser is chosen instead, comments are silently ignored.

• SAXON supports language-dependent sorting and numbering only for English, but offers APIs that allow support of other languages via user-written additions.

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, with the optional addition of a fragment identifier, as described below. 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. The standard URI resolver supports access to XML documents only. A simple fragment identifier is allowed, consisting of the value of an ID attribute in the document. The effect is to return the subdocument rooted at the element with this identifier if there is one, or an empty document otherwise. For example, the URI mydoc.xml#aaa locates the XML document mydoc.xml, and if it contains an element <eeee id="aaa">, where id is an attribute of type ID, then the document retrieved is an XML document with this <eeee> element as its outermost (document) element.

The values of the vendor-specific system properties are:

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 xsl: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

Saxon implements the TRaX API, as defined in JSR-63. Saxon implements the interfaces in the javax.xml.transform package in full, including support for SAX, DOM, and Stream input, and SAX, DOM, and Stream output.

Saxon does not implement the interfaces in javax.xml.parsers, nor does it use these interfaces to obtain a SAX parser or a DOM builder.

Saxon does not support transform() on a DOMSource when the node to be transformed is a node other than the DOM Document element.

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. These actions can be modified by supplying a user-defined ErrorListener.

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

Michael H. Kay
31 January 2001