SAXON home page


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.

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. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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, delete line 172 (the call on checkNumberable()).

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

  1. 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.

  2. 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.

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

  4. 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