Functions, operators, and data types for XPath 2.0

The doc-available(uri) function is available. This returns true if a document with the given URI can be successfully loaded, otherwise false.

The codepoint-equal() function is implemented. This tests whether two strings are equal using the Unicode codepoint collation (unlike the "eq" and "=" operators, which use the default collation, which might be different).

The old names for component access functions, such as get-hours-from-dateTime() have been removed. These functions have been available under their new names (for example hours-from-dateTime) for some releases, but the old names had been retained until now as synonyms, for compatibility.

The rules for the tokenize() function have changed. If the argument is an empty sequence or a zero-length string, the result is now an empty sequence.

The time value 24:00:00 is now permitted in an xs:time or xs:dateTime. The W3C specification is clear that this is allowed, but is not very clear on how it should be handled. Saxon translates it immediately to 00:00:00 on the following day: so for example the expression year-from-dateTime(xs:dateTime('2004-12-31T24:00:00')) returns 2005.

The function resolve-uri no longer raises an error if the supplied base URI is not an absolute URI. For example, the result of resolve-uri('index.html', '/html/base/') is now /html/base/index.html.

The implicit timezone is now maintained as a property of the Configuration. This means that it must be known at compile-time, and it must be the same for all transformations and queries executed under the control of a single Configuration. Although the W3C specifications describe the implicit timezone as part of the dynamic context, they leave it implementation-defined how and when the value is initialized. Making it part of the Configuration means that there is no longer any need for the optimizer to take special steps to avoid performing operations that depend on the implicit timezone (such as subtraction of two times) at compile time. It also makes it safe, for example, to build an index on date/time values and reuse this across multiple transformations. This change brings timezone handling in Saxon closer to the W3C specifications. Note that one implication is that there is no longer any guarantee that the implicit timezone is the same as the timezone used in the result of current-dateTime(), which is taken from the system clock. By default, however, the implicit timezone is the timezone of the machine where Saxon is running, at the time the Configuration is instantiated.