The following names are now reserved, and cannot appear as function names (see A.3 Reserved Function Names):
map
array
The following names are now reserved, and cannot appear as function names (see A.3 Reserved Function Names):
function
namespace-node
switch
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.
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:
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.
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.
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.
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.
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
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.
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
.
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.)
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
.
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.