saxon.README

What is SAXON?

The SAXON package is a collection of tools for processing XML documents. The main components of Saxon 6.5.x are:

An XSLT processor, which implements the Version 1.0 XSLT and XPath Recommendations from the World Wide Web Consortium, found at http://www.w3.org/TR/1999/REC-xslt-19991116 and http://www.w3.org/TR/1999/REC-xpath-19991116 with a number of powerful extensions. This version of Saxon also includes many of the new features that were first defined in the XSLT 1.1 working draft, but for conformance and portability reasons these are not available if the stylesheet header specifies version="1.0".
A Java library, which supports a similar processing model to XSL, but allows full programming capability, which you need if you want to perform complex processing of the data or to access external services such as a relational database
A slightly improved version of the Ælfred parser originally written by David Megginson, then of Microstar. (But you can use SAXON with any SAX-compliant XML parser if you prefer).

So you can use SAXON by writing XSLT stylesheets, by writing Java applications, or by any combination of the two.

SAXON is particularly useful when converting XML data into other formats. The output format may be XML, or HTML, or some other format such as comma separated values, EDI messages, or data in a relational database.

SAXON implements the XSLT 1.0 recommendation, including XPath 1.0, in its entirety. SAXON also provides some XSLT 1.1 features, in particular:

Support for multiple output files using xsl:document. (Saxon was the first processor to provide this feature, which has now found its way into the latest W3C working draft. The xsl:document element replaces the saxon:output instruction offered in previous releases. The implementation of xsl:document at this time is not 100% compliant with the draft XSLT 1.1 specifications).
It allows multi-pass processing, by allowing result-tree-fragments to be used in any context where a node-set can be used. (The saxon:node-set() extension function is still available, but it is now superfluous.)
It supports XML Base, a facility which allows the base URI of an element to be defined using an xml:base attribute.

Note that the XSLT 1.1 working draft was subsequently abandoned. Most of the new functionality (with the exception of Java and Javascript language bindings) reappeared in the XSLT 2.0 drafts, but in some cases with different syntax.

In addition, Saxon provides an extensive library of extension elements and extension functions, all implemented in conformance with the XSLT 1.0 standard to ensure that portable stylesheets can be written. These include the EXSLT extension libraries common, sets, math, dates-and-times, and functions. Many of these extensions were pioneered in Saxon and have since become available in other products.

Saxon also includes a number of powerful extension functions that go beyond EXSLT. Most of these rely on the concept of "stored expressions" as an additional data-type: this allows an XPath expression to be constructed at run-time from a string, and allows an expression to be passed as an argument to a function (which in effect provides higher-order functions). This allows:

distinct() to provide grouping capability on any calculated value
sum(), min() and max(), of any calculated value
expression() and evaluate() to allow an XPath expression to be constructed dynamically, passed to the stylesheet as a parameter, or read from the source document.

As a Java class library, SAXON gives you the ability to use the XSLT rule-based approach to document processing, but with the flexibility of the full Java language. You can declare handler classes to match particular patterns in the document, and can process arbitrary sets of nodes selected using XPath expressions. This provides a high-level query capability which you can mix with purely navigational access.

Changes in version 6.5.4 (2005-06-22)

The TransformerFactoryImpl (Saxon's implementation of the JAXP TransformerFactory class) now supports the method setFeature introduced in JAXP 1.3. However, the "secure processing" feature which the specification says all implementations must provide is not supported.

The Controller (Saxon's implementation of the JAXP Transformer class) now implements the reset() method introduced in JAXP 1.3. Note that the reset() method does not clear the document pool (the collection of documents loaded using the document() function. This is because the purpose of resetting a Transformer rather than creating a new one is in order to reuse resources.

The Saxon tree models implement DOM interfaces. This support has been upgraded so that all DOM level 3 methods are present, as required in order to compile the code under JDK 1.5. In many cases, the new methods are trivial implementations, that is, they typically return null or throw an UnsupportedOperationException if called.

In the NodeInfo interface, the method isSameNode() has been renamed isSameNodeInfo() to avoid conflict with the DOM Level 3 interface of the same name.

To allow compilation under JDK 1.5, variables named "enum" have been renamed.

The algorithm for generating IDs for attribute and namespace nodes has been changed in both the tiny tree and the standard tree. The previous algorithm did not guarantee that the IDs consisted of ASCII alphanumeric characters, as required by the XSLT 1.0 specification.

In version 6.5.3 the following bug was present, and has now been fixed: 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 applied to the TinyTree only.

A performance bug in the implementation of result tree fragments has been fixed. The code in FragmentValue.java used the construct new Vector(20, 20) to allocate space for nodes on the tree; the effect of this is that a fixed allocation unit of 20 items is used, meaning that the cost of constructing the tree increases as the square of the number of nodes.

Several bugs in xsl:number have been fixed:

The implementation now correctly handles a format pattern that contains no formatting tokens, for example format="*" (the resulting output takes the form *12*). {test numb26}
The first non-alphanumeric token in the format picture is no longer treated as a separator token, so if multiple numbers are output using a format picture of (1), the output is now (1.2.3) rather than (1(2(3). {test numb35}
Saxon now returns the correct 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. {test numb32}

An error is now reported if there are two templates in different stylesheet modules with the same name and the same import precedence, provided (a) that there is no template with that name and higher import precedence, and (b) that the template is actually referenced in an xsl:call-template instruction. {test error052}

An error is now reported if a namespace prefix used in the exclude-result-prefixes attribute of the xsl:stylesheet element of an imported or included stylesheet module has not been declared, unless the module is in forwards-compatible mode (for example, because it specifies version="2.0". {test error235}

Within xsl:for-each, any xsl:sort elements must now precede any other instructions. {test error172}

Some previously unreported errors have been found as a result of running Saxon 6.5.4 against the test suite for Saxon 8.5. The following bugs have been fixed:

Saxon 6.5.3 did not fail cleanly when there are too many nested xsl:apply-templates calls. {test error051}
Saxon 6.5.3 threw a NullPointerException if an xsl:stylesheet or xsl:transform element appeared as a child of another element in the stylesheet. {test error236}
Saxon 6.5.3 failed when processing a literal result element appearing within an xsl:fallback instruction. {test ver23}
Saxon 6.5.3 produced an ArrayIndexOutOfBoundsException when serializing an element that (a) is included in the cdata-section-elements attribute of xsl:output, and (b) contains a Unicode character above 65535 (a "supplementary character"). {test output176}
Saxon 6.5.3 threw an ArrayIndexOutOfBounds exception when calling an extension function if the target class contained both a matching static method with N arguments and a matching non-static method with N-1 arguments.
Saxon 6.5.3, when operating in forwards compatibility mode, does not ignore all 1.0 errors (for example, XSLT 2.0 features) appearing within the children of an unrecognized top-level element such as the XSLT 2.0 xsl:function element.
Saxon 6.5.3, when operating in forwards compatibility mode, does not always treat an optional attribute with an unrecognized value as if the attribute were not specified. This is a difficult problem to fix across the board, but it has been fixed for some particular cases that arise when Saxon 6.5.4 is presented with an XSLT 2.0 stylesheet, for example if the mode attribute of xsl:template or xsl:apply-templates is not a valid QName then the attribute is ignored {test cnfr18}. A match pattern that XSLT 1.0 does not allow is now treated (when in forwards compatibility mode) as a pattern that no nodes will match {test ver24} (this is not an explicit rule in the XSLT 1.0 specification, but seems to be the best thing to do given the intent behind forwards compatibility mode.)
In Saxon 6.5.3, the JDOM adapter (when used with the JDOM 1.0 release) did not correctly handle the namespace axis, nor the DocType node in a JDOM tree. It also did not allow access to attributes in the XML namespace (such as xml:space)

Support for FOP has been dropped.

Saxon 6.5.4 is no longer supported under JDK 1.1. In consequence, Instant Saxon, which relied on the Microsoft JVM, is no longer available.

The applet support module XSLTProcessorApplet, and the sample HTML pages illustrating use of Saxon as an applet, have been dropped.