XPath 2.0 implementation
The implementation of the "and" and "or" operators has reverted to two-valued logic, since three-valued logic didn't make it into the published XPath 2.0 working draft. (Actually, it seems 3-valued logic wasn't working in Saxon 7.0 anyway).
Changed the "==" and "!==" operators to "is" and "isnot".
Changed string literals to allow the delimiting quote marks to be doubled. For example,
<xsl:value-of select="'[He isn''t]'"/> displays the string
every expressions to allow multiple range variables,
some $i in //I, $j in //J satisfies $i = $j
Implemented the singleton value-comparison operators (eq, ne, gt, lt, ge, le). These return an error if applied to a sequence containing more than one item, and return the empty sequence if either operand is an empty sequence; when applied to singletons, they return the same result as the XPath 1.0 operators (=, !=, etc).
Less-than and greater-than comparisons between nodes and/or strings now do a lexicographic comparison using the default collating sequence; at XPath 1.0 they did a numeric comparison. A warning is output in this situation (and one or two other situations, but not all) to advise of the backwards incompatibility.
The rules for deciding when path expressions need to be sorted have been revised. As a result many cases now require no sort where previously a sort was done. Examples of such expressions include a/b/c, .//a, $x/a, //@a. In addition, most path expressions that return results in reverse document order are now sorted by a simple reversal, which is much faster than a full sort.
There's a temporary bug in that path expressions returning namespace nodes don't always return them in document order. I'm awaiting resolution of the XPath 2.0 data model rules before fixing this.
Suppress lazy evaluation of assignable variables. (This was designed to prevent a stack overflow, it didn't succeed, but it seems a good idea anyway).
Added the ability for a Source object to be supplied as the value of a stylesheet parameter or as the value returned by an extension function.
Added dateTime and date data types. Initially the only operations supported are the currentDateTime function, the dateTime and date constructors, and conversion between strings, dates, and dateTimes in both directions. Conversion to string uses the timezone of the current locale.
Implemented comparisons (equals, less-than, etc) between dates and dateTimes.
Also implemented sorting. The data-type of xsl:sort may take the two values "text" or "number"
(which are treated as synonyms of xs:string and xs:double) or any XML Schema built-in data type
for which sorting is supported. The values in the sequence to be sorted are converted to this
data type (using the same rules as for
cast as) and the rules for this data type
determine the sort order.
Note that (as required by the XML Schema specification) dateTime values are normalized to UTC. The original timezone specified when the dateTime was constructed is not retained. If no timezone is present, this fact is remembered. Such a dateTime is compared with other dateTimes as if it were a UTC dateTime.
Implemented the instance of operator (including the instance of only variant):
if ($x instance of xs:integer *) then x else y. The types that are currently
supported are the 19 primitive schema types (the namespace may be either of the two namespaces
permitted in XML Schema Part 2), the derived type xs:integer, the node types document, element,
attribute, text, comment, processing-instruction, or namespace, and the abstract types node, and item.
(There is no syntax currently for the general numeric type or for the general atomic type). The
type name may be followed by one of the qualifiers "*", "+", or "?" to indicate the number of
occurrences; if there is no qualifier, there must be exactly one occurrence. The more sophisticated
forms of type-checking, using schema-defined complex types, are not yet supported.
Implemented the cast as data-type expression, for example
cast as xs:boolean($x).
The conversion rules are the same as those which apply implicitly when a value is supplied
in a context where a different type is expected.
Implemented the treat as data-type expression. This doesn't actually have much use in an XSLT context, where type conversion is performed implicitly when required, and the semantics of the expression are probably not correctly implemented at this stage: the specification is still evolving.