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 [He isn't]

Changed the some and every expressions to allow multiple range variables, for example 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[1]/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): for example 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.