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.

## 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
5 January 2005