H Backwards Compatibility (Non-Normative)

H.1 Incompatibilities relative to XPath 3.1

None.

H.2 Incompatibilities relative to XPath 3.0

The following names are now reserved, and cannot appear as function names (see A.3 Reserved Function Names):

H.3 Incompatibilities relative to XPath 2.0

The following names are now reserved, and cannot appear as function names (see A.3 Reserved Function Names):

If U is a union type with T as one of its members, and if E is an element with T as its type annotation, the expression E instance of element(*, U) returns true in both XPath 3.0 and 3.1. In XPath 2.0, it returns false.

Note:

This is not an incompatibility with XPath 3.0. It should be included in XPath 3.0 as an incompatibility with XPath 2.0 but it was discovered after publication.

H.4 Incompatibilities relative to XPath 1.0

This appendix provides a summary of the areas of incompatibility between XPath 4.0 and [XML Path Language (XPath) Version 1.0]. In each of these cases, an XPath 4.0 processor is compatible with an XPath 2.0, 3.0, or 3.1 processor.

Three separate cases are considered:

  1. Incompatibilities that exist when source documents have no schema, and when running with XPath 1.0 compatibility mode set to true. This specification has been designed to reduce the number of incompatibilities in this situation to an absolute minimum, but some differences remain and are listed individually.

  2. Incompatibilities that arise when XPath 1.0 compatibility mode is set to false. In this case, the number of expressions where compatibility is lost is rather greater.

  3. Incompatibilities that arise when the source document is processed using a schema (whether or not XPath 1.0 compatibility mode is set to true). Processing the document with a schema changes the way that the values of nodes are interpreted, and this can cause an XPath expression to return different results.

H.4.1 Incompatibilities when Compatibility Mode is true

The list below contains all known areas, within the scope of this specification, where an XPath 4.0 processor running with compatibility mode set to true will produce different results from an XPath 1.0 processor evaluating the same expression, assuming that the expression was valid in XPath 1.0, and that the nodes in the source document have no type annotations other than xs:untyped and xs:untypedAtomic.

Incompatibilities in the behavior of individual functions are not listed here, but are included in an appendix of [XQuery and XPath Functions and Operators 4.0].

Since both XPath 1.0 and XPath 4.0 leave some aspects of the specification implementation-defined, there may be incompatibilities in the behavior of a particular implementation that are outside the scope of this specification. Equally, some aspects of the behavior of XPath are defined by the host language.

  1. Consecutive comparison operators such as A < B < C were supported in XPath 1.0, but are not permitted by the XPath 4.0 grammar. In most cases such comparisons in XPath 1.0 did not have the intuitive meaning, so it is unlikely that they have been widely used in practice. If such a construct is found, an XPath 4.0 processor will report a syntax error, and the construct can be rewritten as (A < B) < C

  2. When converting strings to numbers (either explicitly when using the number function, or implicitly say on a function call), certain strings that converted to the special value NaN under XPath 1.0 will convert to values other than NaN under XPath 4.0. These include any number written with a leading + sign, any number in exponential floating point notation (for example 1.0e+9), and the strings INF and -INF.

    Furthermore, the strings Infinity and -Infinity, which were accepted by XPath 1.0 as representations of the floating-point values positive and negative infinity, are no longer recognized. They are converted to NaN when running under XPath 4.0 with compatibility mode set to true, and cause a dynamic error when compatibility mode is set to false.

  3. XPath 4.0 does not allow a token starting with a letter to follow immediately after a numeric literal, without intervening whitespace. For example, 10div 3 was permitted in XPath 1.0, but in XPath 4.0 must be written as 10 div 3.

  4. The namespace axis is deprecated as of XPath 2.0. Implementations may support the namespace axis for backward compatibility with XPath 1.0, but they are not required to do so. (XSLT 2.0 requires that if XPath backwards compatibility mode is supported, then the namespace axis must also be supported; but other host languages may define the conformance rules differently.)

  5. In XPath 1.0, the expression -x|y parsed as -(x|y), and returned the negation of the numeric value of the first node in the union of x and y. In XPath 4.0, this expression parses as (-x)|y. When XPath 1.0 Compatibility Mode is true, this will always cause a type error.

  6. The rules for converting numbers to strings have changed. These may affect the way numbers are displayed in the output of a stylesheet. For numbers whose absolute value is in the range 1E-6 to 1E+6, the result should be the same, but outside this range, scientific format is used for non-integral xs:float and xs:double values.

  7. If one operand in a general comparison is a single atomic value of type xs:boolean, the other operand is converted to xs:boolean when XPath 1.0 compatibility mode is set to true. In XPath 1.0, if neither operand of a comparison operation using the <, <=, > or >= operator was a node set, both operands were converted to numbers. The result of the expression true() > number('0.5') is therefore true in XPath 1.0, but is false in XPath 4.0 even when compatibility mode is set to true.

  8. In XPath 4.0, a type error is raised if the PITarget specified in a SequenceType of form processing-instruction(PITarget) is not a valid NCName. In XPath 1.0, this condition was not treated as an error.

H.4.2 Incompatibilities when Compatibility Mode is false

Even when the setting of the XPath 1.0 compatibility mode is false, many XPath expressions will still produce the same results under XPath 4.0 as under XPath 1.0. The exceptions are described in this section.

In all cases it is assumed that the expression in question was valid under XPath 1.0, that XPath 1.0 compatibility mode is false, and that all elements and attributes are annotated with the types xs:untyped and xs:untypedAtomic respectively.

In the description below, the terms node-set and number are used with their XPath 1.0 meanings, that is, to describe expressions which according to the rules of XPath 1.0 would have generated a node-set or a number respectively.

  1. When a node-set containing more than one node is supplied as an argument to a function or operator that expects a single node or value, the XPath 1.0 rule was that all nodes after the first were discarded. Under XPath 4.0, a type error occurs if there is more than one node. The XPath 1.0 behavior can always be restored by using the predicate [1] to explicitly select the first node in the node-set.

  2. In XPath 1.0, the < and > operators, when applied to two strings, attempted to convert both the strings to numbers and then made a numeric comparison between the results. In XPath 4.0, these operators perform a string comparison using the default collating sequence. (If either value is numeric, however, the results are compatible with XPath 1.0)

  3. When an empty node-set is supplied as an argument to a function or operator that expects a number, the value is no longer converted implicitly to NaN. The XPath 1.0 behavior can always be restored by using the number function to perform an explicit conversion.

  4. More generally, the supplied arguments to a function or operator are no longer implicitly converted to the required type, except in the case where the supplied argument is of type xs:untypedAtomic (which will commonly be the case when a node in a schemaless document is supplied as the argument). For example, the function call substring-before(10 div 3, ".") raises a type error under XPath 4.0, because the arguments to the substring-before function must be strings rather than numbers. The XPath 1.0 behavior can be restored by performing an explicit conversion to the required type using a constructor function or cast.

  5. The rules for comparing a node-set to a boolean have changed. In XPath 1.0, an expression such as $node-set = true() was evaluated by converting the node-set to a boolean and then performing a boolean comparison: so this expression would return true if $node-set was non-empty. In XPath 4.0, this expression is handled in the same way as other comparisons between a sequence and a singleton: it is true if $node-set contains at least one node whose value, after atomization and conversion to a boolean using the casting rules, is true.

    This means that if $node-set is empty, the result under XPath 4.0 will be false regardless of the value of the boolean operand, and regardless of which operator is used. If $node-set is non-empty, then in most cases the comparison with a boolean is likely to fail, giving a dynamic error. But if a node has the value "0", "1", "true", or "false", evaluation of the expression may succeed.

  6. Comparisons of a number to a boolean, a number to a string, or a string to a boolean are not allowed in XPath 4.0: they result in a type error. In XPath 1.0 such comparisons were allowed, and were handled by converting one of the operands to the type of the other. So for example in XPath 1.0 4 = true() was true; 4 = "+4" was false (because the string +4 converts to NaN), and false = "false" was false (because the string "false" converts to the boolean true). In XPath 3.0 all these comparisons are type errors.

  7. Additional numeric types have been introduced, with the effect that arithmetic may now be done as an integer, decimal, or single- or double-precision floating point calculation where previously it was always performed as double-precision floating point. The result of the div operator when dividing two integers is now a value of type decimal rather than double. The expression 10 div 0 raises an error rather than returning positive infinity.

  8. The rules for converting strings to numbers have changed. The implicit conversion that occurs when passing an xs:untypedAtomic value as an argument to a function that expects a number no longer converts unrecognized strings to the value NaN; instead, it reports a dynamic error. This is in addition to the differences that apply when backwards compatibility mode is set to true.

  9. Many operations in XPath 4.0 produce an empty sequence as their result when one of the arguments or operands is an empty sequence. Where the operation expects a string, an empty sequence is usually considered equivalent to a zero-length string, which is compatible with the XPath 1.0 behavior. Where the operation expects a number, however, the result is not the same. For example, if @width returns an empty sequence, then in XPath 1.0 the result of @width+1 was NaN, while with XPath 4.0 it is (). This has the effect that a filter expression such as item[@width+1 != 2] will select items having no width attribute under XPath 1.0, and will not select them under XPath 4.0.

  10. The typed value of a comment node, processing instruction node, or namespace node under XPath 4.0 is of type xs:string, not xs:untypedAtomic. This means that no implicit conversions are applied if the value is used in a context where a number is expected. If a processing-instruction node is used as an operand of an arithmetic operator, for example, XPath 1.0 would attempt to convert the string value of the node to a number (and deliver NaN if unsuccessful), while XPath 4.0 will report a type error.

  11. In XPath 1.0, it was defined that with an expression of the form A and B, B would not be evaluated if A was false. Similarly in the case of A or B, B would not be evaluated if A was true. This is no longer guaranteed with XPath 4.0: the implementation is free to evaluate the two operands in either order or in parallel. This change has been made to give more scope for optimization in situations where XPath expressions are evaluated against large data collections supported by indexes. Implementations may choose to retain backwards compatibility in this area, but they are not obliged to do so.

  12. In XPath 1.0, the expression -x|y parsed as -(x|y), and returned the negation of the numeric value of the first node in the union of x and y. In XPath 4.0, this expression parses as (-x)|y. When XPath 1.0 Compatibility Mode is false, this will cause a type error, except in the situation where x evaluates to an empty sequence. In that situation, XPath 4.0 will return the value of y, whereas XPath 1.0 returned the negation of the numeric value of y.

H.4.3 Incompatibilities when using a Schema

An XPath expression applied to a document that has been processed against a schema will not always give the same results as the same expression applied to the same document in the absence of a schema. Since schema processing had no effect on the result of an XPath 1.0 expression, this may give rise to further incompatibilities. This section gives a few examples of the differences that can arise.

Suppose that the context node is an element node derived from the following markup: <background color="red green blue"/>. In XPath 1.0, the predicate [@color="blue"] would return false. In XPath 4.0, if the color attribute is defined in a schema to be of type xs:NMTOKENS, the same predicate will return true.

Similarly, consider the expression @birth < @death applied to the element <person birth="1901-06-06" death="1991-05-09"/>. With XPath 1.0, this expression would return false, because both attributes are converted to numbers, which returns NaN in each case. With XPath 4.0, in the presence of a schema that annotates these attributes as dates, the expression returns true.

Once schema validation is applied, elements and attributes cannot be used as operands and arguments of expressions that expect a different data type. For example, it is no longer possible to apply the substring function to a date to extract the year component, or to a number to extract the integer part. Similarly, if an attribute is annotated as a boolean then it is not possible to compare it with the strings "true" or "false". All such operations lead to type errors. The remedy when such errors occur is to introduce an explicit conversion, or to do the computation in a different way. For example, substring-after(@temperature, "-") might be rewritten as abs(@temperature).

In the case of an XPath 4.0 implementation that provides the static typing feature, many further type errors will be reported in respect of expressions that worked under XPath 1.0. For example, an expression such as round(../@price) might lead to a static type error because the processor cannot infer statically that ../@price is guaranteed to be numeric.

Schema validation will in many cases perform whitespace normalization on the contents of elements (depending on their type). This will change the result of operations such as the string-length function.

Schema validation augments the data model by adding default values for omitted attributes and empty elements.