Limitations
This page lists areas where Saxon 6.5.4 is known to be non-conformant with W3C specifications.
Since Saxon 6.5.4 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 65535.
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.
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.
Saxon does not allow attribute and namespace nodes to be numbered using <xsl:number level="single">.
This should be permitted according to the specification, and
if the count and from patterns are omitted the result should always be 1 (one).
This bug can be fixed by the following source change: in module com.icl.saxon.om.Navigator,
delete line 172 (the call on checkNumberable()).
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.
When the output file name supplied to a StreamResult contains spaces or other special characters,
then under Java 5 (or JAXP 1.3) the file that is actually created will contain these special characters in %HH notation.
For example, if the output is created as new StreamResult('test.out'), and the current directory is
c:\My Documents\, then the resulting output file will be in c:\My%20Documents\test.out.
This problem also occurs when the transformation is run from the command line. The cause of the problem is that
JAXP 1.3 corrects a long-standing bug whereby spaces and other special characters were not %HH encoded when
converting the supplied filename to a URI; unfortunately Saxon doesn't attempt to reverse the %HH encoding when
converting the URI back to a filename. This is partly because the JVM methods to do this were introduced only
in JDK 1.4, and Saxon 6.5.4 is supported also on JDK 1.2 and JDK 1.3.
The code that needs to be fixed is in method urlToFileName in class GeneralOutputter.
No fix is currently available. For JDK 1.4 and later, the method can be replaced by a call on
new File(new URI(base)).toString(), with suitable exception handling, but a correct solution
for JDK 1.3 and earlier would require implementation of a URI decoder that handles all %HH escape sequences.
Note that this problem affects Saxon 6.5.3 as well as 6.5.4. It is not present in Saxon 8.x.
Michael H. Kay
15 August 2005