SAXON home page

Limitations

This page lists areas where Saxon 6.5.3 is known to be non-conformant with W3C specifications.

Since Saxon 6.5.3 is now stable and generally reliable, I have no intention of removing these limitations.

XSLT 1.0 conformance

  1. The characters used in the xsl:decimal-format element and the picture string of format-number must have Unicode code points less than 65535.

  2. When Saxon is run with a Java version later than 1.1, the picture string of format-number behaves as implemented in that version of the Java DecimalFormat class, whereas the XSLT specification mandates that it should behave as specified in JDK 1.1.

  3. The output of generate-id for an attribute or namespace node may contain non-ASCII or non-alphanumeric characters if the name of the attribute or namespace node contains such characters.

  4. When the version attribute is set to 1.1, Saxon recognizes certain constructs that were defined in the draft XSLT 1.1 specification; XSLT 1.0 requires that such constructs are treated as errors.

  5. An erratum to the XSLT 1.0 specification states that xsl:copy and xsl:copy-of may be used to add a namespace node to a newly constructed element. This works correctly in Saxon, provided that the name of the namespace node does not clash with the namespace prefix that Saxon has allocated to the element for serialization purposes. (In principle, this namespace prefix should not be present in the result tree, and should therefore be incapable of causing a conflict.) More details: see bug 637117.

  6. Saxon's checking of the characters used in a QName is an approximation to the rules in the XML specification. Some rarely-used characters are permitted when they should be rejected, and there may also be a few cases where valid characters are rejected.

  7. When comparing two nodes for identity (e.g. when evaluating the union operator |), an element, text, comment or PI node may be considered identical to an attribute or namespace node if they happen to be at the same offset in their respective data structures. This problem applies to the TinyTree only.

    The fix for this (tested with 7.6.5) is to add the test:
    if (this.getNodeType() != other.getNodeType()) return false;
    at line 63 of module com.icl.saxon.tinytree.TinyNodeImpl

  8. When the format attribute of xsl:number contains a punctuation token but no formatting tokens (for example format="*") Saxon fails with an ArrayIndexOutOfBoundsException. {Test case numb26}

  9. Saxon reports no error when two named templates in different stylesheet modules have the same name and the same import precedence. It simply uses the one that comes last.

  10. If one of the namespace prefixes declared in the exclude-result-prefixes or extension-element-prefixes attribute of the xsl:stylesheet element of an included or imported stylesheet module is not the prefix of a declared namespace, then no error is reported, and all the prefixes in the attribute are ignored.

  11. Within xsl:for-each, Saxon reports no error if xsl:sort elements are preceded by other instructions. It behaves as if the xsl:sort elements appeared first.

  12. Saxon reports no error if the xsl:with-param element is misspelt, for example as xsl:width-param. The misspelt element is silently ignored.

  13. Saxon may report a spurious circularity in attribute-set definitions. The problem occurs if two attribute-sets in different stylesheet modules happen to share the same node-identifier within their respective documents, and if one references the other directly or indirectly.

    The fix for this (tested but not regression tested) is: in com.icl.saxon.Controller, in methods getUserData() and setUserData() (lines 830/843), change the lines declaring the variable key to:

    String key = name + " " + getDocumentPool().getDocumentNumber(node.getDocumentRoot()) + node.generateId();

  14. Saxon returns incorrect results for <xsl:number level="any"> when the context node is an attribute that does not match the count pattern, and when its parent is an element that does match the count pattern. The error occurs only when using the tiny tree model.

  15. Saxon treats all non-alphanumeric tokens in the format string of <xsl:number> as separator tokens. This means that if multiple numbers are output (using level="multiple") with a format such as (1), the output has the form (3(5(1) whereas the correct interpretation of the specification produces (3.5.1).

    The fix for this (tested but not regression tested) is: in com.icl.saxon.number.NumberFormatter, at line 110, replace the line sb.append((String)separators.elementAt(tok)); by:

                    if (tok==0 && startsWithSeparator) {
                        // The first punctuation token isn't a separator if it appears before the first
                        // formatting token. Such a punctuation token is used only once, at the start.
                        sb.append(".");
                    } else {
                        sb.append((String)separators.get(tok));
                    }
    

  16. When sorting is applied to a the result of an expression that should return a node-set, duplicate nodes are not always removed from the node-set. For example, this happens if sorting is applied to the result of the id() function, if the argument to the id() function is such that the same node is selected several times. If the result is not sorted, duplicates are eliminated correctly.

    The fix for this (tested but not regression tested) is in line 136 of SortedSelection.java: change selection.enumerate(context, false) to selection.enumerate(context,true).

XML 1.0 Conformance

The default parser is a version of Ælfred. There is one known non-conformance in the version of the AElfred parser provided with the Saxon product: it does not enforce the constraint that the contents of a general entity must be well-formed. Note, however, that this parser does not perform XML validation.

JAXP Conformance

When stylesheet output is sent to a user-provided ContentHandler, it's best only to send a well-formed document. If the result tree is not well-formed, Saxon tries to tell the ContentHandler about it by means of a saxon:warning processing instruction. However, failures are likely to follow whether the application responds to this warning or not. It's not clear what the right thing to do is here; it doesn't seem right to send a ContentHandler an ill-formed event stream, as it's likely to break. Saxon 7.x adopts the cleaner approach of defining an output property saxon:require-well-formed="no" to indicate that the ContentHandler is prepared to accept an ill-formed event stream.

If the command line (com.icl.saxon.StyleSheet) is invoked with the source document and/or stylesheet specified as URLs, and a user-written URIResolver is used, and the resolve() method returns null for the URIs on the command line, then Saxon doesn't try to use the standard URIResolver instead.

Whitespace stripping does not take place when the transformation is executed using a JAXP TransformerHandler.


Michael H. Kay
6 June 2005