This file describes changes for versions 7.0 and later. For changes prior to version 7.0, see http://saxon.sf.net/saxon6.5/changes.html.
This version introduces initial support of features defined in working drafts of XSLT 2.0 and XPath 2.0.
Version 7.0 should be regarded as an experimental alpha release. For production use, please continue to use Saxon 6.5
The Saxon package name has changed from com.icl.saxon to net.sf.saxon.
Any applications that use Saxon java classes directly (rather than relying on the JAXP
interface) will need to be modified. Note that this also affects the settings of the system
The entry point from the command line has changed from com.icl.saxon.StyleSheet to net.sf.saxon.Transform.
The namespace URI for saxon extensions has changed from http://icl.com/saxon to http://saxon.sf.net/. Note that many extensions have been withdrawn, as they are superseded by facilities in XPath 2.0 and/or XSLT 2.0.
To allow coexistence, the name of the JAR file for this release has changed to
saxon7.jar. The SQL extensions are now in a separate JAR file,
A transformation can now be executed directly from the JAR file using the command
java -jar saxon7.jar in place of
Saxon now requires JDK 1.2 or later to run. In consequence, Saxon will no longer work with the Microsoft Java VM, and the Instant Saxon version of the product is therefore no longer available.
Because Saxon no longer runs with the Java VM, it can now be run as an applet within Internet Explorer only if the Sun Java plug-in is installed. You can get this from http://java.sun.com/getjava. This may require some configuration changes because of the differences in security policy.
The following sections summarize the main new features. These assume familiarity with the XPath 2.0 and XSLT 2.0 specifications; however, summaries of the new syntax for expressions and XSLT elements are included in this package.
($a, $b, $c). Path expressions now return a sequence of nodes containing no duplicates, in document order.
1 to 10evaluates to the sequence
( 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 )
*:localname(like prefix:*) is allowed in path expressions, and also in patterns and in
xsl:strip-spaceand xsl:preserve-space. It matches any node with the given local name, regardless of namespace.
xsl:value-ofelement has a new
separatorattribute, so it can be used to output a sequence.
xsl:for-eachelement supports arbitrary sequences.
xsl:for-each-groupinstruction, and the associated
current-group()function, are implemented.
xsl:resultelements are implemented; these replace
exslt:function. Note that the XSLT 2.0 specification is more restrictive as to what can appear in a function body: it has to be zero or more
xsl:paramelements, followed by zero or more
xsl:variableelements, followed by an
xsl:resultelement. However, this is not a serious restriction in practice, because most computations can now be carried out within a single XPath expression.
xsl:namespaceinstruction is implemented (it writes a namespace node to the result tree)
xsl:copy-ofcan now handle sequences containing simple-values (the simple value is converted to a string and written to the result tree). However, the
separatorattribute is not yet implemented.
xsl:documentelement (and its synonym
saxon:output) are replaced by
xsl:result-document. This no longer includes the serialization attributes directly, instead it refers by name to an
xsl:outputdeclaration, or can use the unnamed
xsl:outputdeclaration by default.
xsl:outputelement now supports
method="saxon:xhtml". The precise details of the output may not be fully conformant with the specification.
xsl:destinationelement is provided, however, since the
hrefattribute is currently ignored, it is not very useful at this stage.
saxon:handlerelement is no longer supported.
xsl:scriptelement is no longer supported - however, the synonym
collationattribute has been added to
xsl:sort, and the implementation of sorting now uses JDK 1.2 collators. The
collationattribute must match the name attribute of a
saxon:collationelement. If none is specified, the
langattribute is now used to select a collator, or if the
langattribute is omitted, a collator is obtained for the default locale.
xsl:sort-keyelement. A named sort key may be used to perform a sort from within an XPath expression, using the new XSLT-defined
I have made the following changes to the function library:
saxon:distinct()extension function now works on any sequence.
sum()functions now ork on any sequence, and new functions
lower-case(). These use the rules defined by the Java default locale
saxon:range()extension function (it can now be done using the syntax "a to b")
saxon:tokenize()to return a sequence of strings instead of a node-set
key()so that the second argument can be any sequence; each member of the sequence is converted to a string and treated as a potential key value
document()so that the first argument can be any sequence; each member of the sequence can be a URI of a document to be loaded.
saxon:node-set()extension function, which is now obsolete.
saxon:if()extension function, which is superseded by XPath 2.0 conditional expressions.
saxon:closure()function is temporarily withdrawn, because it relies on non-standard use of the
node-set()function in the EXSLT common module is now a no-op; the object-type() function returns one of "sequence", "boolean", "number", "string", or "external".
lowest()in the EXSLT
mathmodule to work on arbitrary sequences.
not3()(three-valued not() function)
saxon:for-all(): these are superseded by the
everyconstructs in XPath 2.0
compare()function: the third argument (collation) is initially mandatory, and must be a QName matching a
base-uri()function replacing the undocumented
float()is the only way of creating a single-precision floating point number.
In general, features of XSLT 2.0 and XPath 2.0 not listed above have not been implemented. In particular, these include:
As might be expected, the Saxon code has undergone major change internally, which will affect any application making significant use of internal interfaces. Here are some of the highlights:
forexpressions. It is also used in various other contexts, e.g. in the implementation of the document(), key() and id() functions.
getStringValue, this allows both SimpleValues and Nodes to implement the new Item interface, which represents a member of a sequence.
net.sf.saxon.value, now contains all the data-type related classes.
I have removed documentation of the saxon:trace extension attribute; it seems this hasn't been working for some time.
Contextclass no longer implements the XSLT 1.1 WD interface org.w3c.xsl.XSLTContext.
com.icl.saxon.handlers(ElementHandler etc). It is still possible for a Java application to register a NodeHandler to receive events; this must now be written as an implementation of the net.sf.saxon.NodeHandler interface. See the ShowBooks.java sample application to see how.
langattribute of xsl:sort; instead, it must be specified using the
collationattribute, with a
saxon:collationelement that maps the named collation to a Java class that implements the JDK
sql:query instruction has been added, to accompany the
|table||The table to be queried (the contents of the FROM clause of the select statement). This is mandatory, the value is an attribute value template.|
|column||The columns to be retrieved (the contents of the SELECT clause of the select statement). May be "*" to retrieve all columns. This is mandatory, the value is an attribute value template.|
|where||The conditions to be applied (the contents of the WHERE clause of the select statement). This is optional, if present the value is an attribute value template.|
|row-tag||The element name to be used to contain each row. Must be a simple name (no colon allowed). Default is "row".|
|column-tag||The element name to be used to contain each column. Must be a simple name (no colon allowed). Default is "col".|
xsl:query instruction writes zero or more row elements to the current
result tree, each containing zero or more column elements, which contain the data values.
Thanks to Claudio Thomas [firstname.lastname@example.org] who supplied the original version of this code.
The SQL extensions are now contained in a separate JAR file,
which must be on the class path if these extensions are used.
Michael H. Kay
20 December 2001