Limitations
This page lists areas where Saxon 6.5.5 is known to be non-conformant with W3C specifications.
Since Saxon 6.5.5 is now stable and generally reliable, there are no plans to remove 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 65536. (This is arguably in conformance with the specification, since XSLT 1.0 refers to
the specification of the DecimalFormat
class in JDK 1.1, which has the same
limitation.)
The picture string of
format-number
behaves as implemented in the Java
DecimalFormat
class for the JDK version in use, whereas
the XSLT specification mandates that it should behave as specified in JDK 1.1.
The "alphanumeric" characters recognized in the format picture of xsl:number
are limited to characters whose Unicode code points are less than 65536. The effect of using
characters above this range in the format picture is undefined.
When the format-token supplied to xsl:number
is x391 or x3b1, that is,
upper or lower case Greek, the representations of the numbers 13-18 are incorrect.
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.
According to the W3C specification,
global variables should be evaluated with the context node set to the root node of the
principal source document. However, when one global variable G contains a forwards reference to another
global variable H, Saxon evaluates H using the dynamic context of the variable reference.
This means that if G contains an xsl:for-each
instruction that changes the context,
and the reference to H occurs within the xsl:for-each
loop, then H is evaluated
with the wrong context. This bug is present in all Saxon versions up to and including 6.5.5.
When characters are used in a comment or processing instruction that cannot be
represented using the encoding chosen in xsl:output
, the specification states
that an error should be signaled. Saxon however replaces the character with a substitute
character and completes the transformation successfully. If the comment or processing instruction
precedes the first element, and the output method is defaulted, then the leading comments and
processing instructions are incorrectly output as a text node containing escaped markup (which means
the output will not be well-formed).
When a node-set is supplied as the first argument to the document()
function, and
two nodes in this node-set refer to the same target document, the result of the document()
function will contain the same document node more than once: duplicates are not eliminated.
When the argument to the function-available()
function is not a string literal,
that is, when it is computed at run-time, the function may return false in cases where it should return
true. Specifically, this happens when the string used at run-time has not been interned, which will be the
case for example if it is obtained as the string value of a node in a source document.
A null pointer exception occurs if the xsl:stylesheet
element has a child element
also called xsl:stylesheet
.
A null pointer exception occurs under some circumstances if a predicate in a match pattern contains
a call on the function starts-with()
with the wrong number of arguments.
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.
Michael H. Kay
24 September 2012