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.
The characters used in the xsl:decimal-format element and the
picture string of format-number must have Unicode code points
less than 65535.
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.
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.
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.
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.
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.
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
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}
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.
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.
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.
Saxon reports no error if the xsl:with-param element is misspelt, for example as
xsl:width-param. The misspelt element is silently ignored.
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();
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.
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));
}
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).
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.
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