Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document addresses errors in the XML Path Language (XPath) 2.0 Recommendation published on 23 January 2007. It records all errors that, at the time of this document's publication, have solutions that have been approved by the XSL Working Group and/or the XML Query Working Group. For updates see the latest version of that document.
The errata are numbered, classified as Substantive, Editorial, or Markup, and are listed in reverse chronological order of their date of origin. Each entry contains the following information:
A description of the error.
A reference to the Bugzilla entry recording the original problem report, subsequent discussion, and resolution by the Working Group.
Key dates in the process of resolving the error.
Where appropriate, one or more textual changes to be applied to the published Recommendation.
Colored boxes and shading are used to help distinguish new text from old, however these visual clues are not essential to an understanding of the change. The styling of old and new text is an approximation to its appearance in the published Recommendation, but is not normative. Hyperlinks are shown underlined in the erratum text, but the links are not live.
A number of indexes appear at the end of the document.
Substantive corrections are proposed by the XSL Working Group and/or the XQuery Working Group (both part of the XML Activity), which have consensus that they are appropriate; they are not to be considered normative until approved by a Call for Review of Proposed Corrections or a Call for Review of an Edited Recommendation.
Please report errors in this document using W3C's public Bugzilla system (instructions can be found at http://www.w3.org/XML/2005/04/qt-bugzilla). If access to that system is not feasible, you may send your comments to the W3C XSLT/XPath/XQuery public comments mailing list, public-qt-comments@w3.org. It will be very helpful if you include the string [XPerrata] in the subject line of your report, whether made in Bugzilla or in email. Each Bugzilla entry and email message should contain only one error report. Archives of the comments and responses are available at http://lists.w3.org/Archives/Public/public-qt-comments/.
Errata
XP.E5 This erratum clarifies the conditions under which a castable expression may raise an error.
XP.E4 This erratum adds more details to the rules defining permissible expression rewrites for optimization and other purposes.
XP.E3 For valid syntax, parentheses need to be added to the expansion for leading "/" and leading "//" in a path expression.
XP.E2 Some incompatibilities from XPath 1.0 are undocumented; others are wrongly classified as applying only when compatibility mode is false.
XP.E1 Spelling mistake: minimum
Indexes
See Bug 4873
This erratum clarifies the conditions under which a castable
expression may raise an error.
19 Sep 2007: Proposed
20 Nov 2007: Accepted
In 3.10.3 Castable (second paragraph):
Replace the text:
The expression V castable
as T returns true if the value V can
be successfully cast into the target type T by using a
cast expression; otherwise it returns
false. The castable expression can be used as a predicate to
avoid errors at evaluation time. It can also be used to select an
appropriate type for processing of a given value, as illustrated in
the following example:
By:
The expression E castable as T returns true if the
result of evaluating E can be successfully
cast into the target type T by using
a cast expression; otherwise it returns false.
If evaluation of E fails with a dynamic error, the
castable expression as a whole fails.
The castable expression can be used as a
predicate to
avoid errors at evaluation time. It can also be used to select an
appropriate type for processing of a given value, as illustrated in
the following example:
See Bug 4446
This erratum adds more details to the rules defining permissible expression rewrites for optimization and other purposes.
19 Sep 2007: Proposed
20 Nov 2007: Accepted
In 2.3.4 Errors and Optimization (twelfth paragraph):
Replace the text:
For a variety of reasons, including optimization, implementations are free to rewrite expressions into equivalent expressions. Other than the raising or not raising of errors, the result of evaluating an equivalent expression must be the same as the result of evaluating the original expression. Expression rewrite is illustrated by the following examples.
By:
For a variety of reasons, including optimization, implementations MAY rewrite expressions into a different form. There are a number of rules that limit the extent of this freedom:
Other than the raising or not raising of errors, the result of evaluating a rewritten expression MUST conform to the semantics defined in this specification for the original expression.
Note:
This allows an implementation to return a result in cases where the original expression would have raised an error, or to raise an error in cases where the original expression would have returned a result. The main cases where this is likely to arise in practice are (a) where a rewrite changes the order of evaluation, such that a subexpression causing an error is evaluated when the expression is written one way and is not evaluated when the expression is written a different way, and (b) where intermediate results of the evaluation cause overflow or other out-of-range conditions.
Note:
This rule does not mean that the result of the expression will always be the same in non-error cases as if it had not been rewritten, because there are many cases where the result of an expression is to some degree implementation-dependent or implementation-defined.
Conditional expressions
MUST NOT raise a dynamic error in
respect of subexpressions occurring in a branch that is not selected,
and MUST NOT
return the value delivered by a branch unless that branch is selected.
Thus, the following example MUST NOT raise a
dynamic error if the document abc.xml does not exist:
if (doc-available('abc.xml')) then doc('abc.xml') else ()
As stated earlier, an expression
MUST NOT be rewritten to dispense with a
required cardinality check: for example, string-length(//title)
MUST raise an
error if the document contains more than one title element.
Expressions MUST NOT be rewritten in such a way as to create or remove static errors. For example, there is a rule that in casting a string to a QName the operand must be a string literal. This rule applies to the original expression and not to any rewritten form of the expression.
Expression rewrite is illustrated by the following examples.
In 2.3.4 Errors and Optimization (second bulleted list, second item, second paragraph):
Replace the text:
To avoid unexpected errors caused by expression rewrite,
tests that are designed to prevent dynamic errors should be expressed
using conditional expressions. Conditional expressions raise only dynamic errors that occur in the branch that is actually
selected. Thus, unlike the previous example, the following example cannot raise a dynamic error if @x is not castable into an xs:date:
By:
To avoid unexpected errors caused by expression rewrite, tests that are designed to prevent dynamic errors should be expressed using conditional expressions. For example, the above expression can be written as follows:
See Bug 4868
For valid syntax, parentheses need to be added to the expansion for leading "/" and leading "//" in a path expression.
10 Aug 2007: Proposed
20 Nov 2007: Accepted
In 3.2 Path Expressions (third paragraph):
Replace the text:
A "/"
at the beginning of a path expression is an abbreviation for
the initial step fn:root(self::node()) treat as
document-node()/ (however, if the
"/" is the entire path expression, the trailing "/" is omitted from the expansion.) The effect
of this initial step is to begin the path at the root node of
the tree that contains the context node. If the context item
is not a node, a type
error is raised [err:XPTY0020]. At
evaluation time, if the root node above the context node is
not a document node, a dynamic error is
raised [err:XPDY0050].
By:
A "/"
at the beginning of a path expression is an abbreviation for
the initial step
(fn:root(self::node())
treat as document-node())/
(however, if the "/" is the entire path expression,
the trailing "/" is omitted from the expansion.) The effect
of this initial step is to begin the path at the root node of
the tree that contains the context node. If the context item
is not a node, a type
error is raised [err:XPTY0020]. At
evaluation time, if the root node above the context node is
not a document node, a dynamic error is
raised [err:XPDY0050].
In 3.2 Path Expressions (fourth paragraph):
Replace the text:
A "//" at the beginning of a path expression
is an abbreviation for the initial steps
fn:root(self::node()) treat as
document-node()/descendant-or-self::node()/ (however, "//" by itself is not a valid path expression [err:XPST0003].) The
effect of these initial steps is to establish an initial node
sequence that contains the root of the tree in which the
context node is found, plus all nodes descended from this
root.
This node sequence is used as the input to subsequent steps
in the path expression. If the context item is not a node, a
type error is
raised [err:XPTY0020]. At evaluation time, if the
root node above the context node is not a document node, a
dynamic error is
raised [err:XPDY0050].
By:
A "//" at the beginning of a path expression
is an abbreviation for the initial steps
(fn:root(self::node()) treat as
document-node())/descendant-or-self::node()/
(however, "//" by itself is not a valid path
expression [err:XPST0003].) The
effect of these initial steps is to establish an initial node
sequence that contains the root of the tree in which the
context node is found, plus all nodes descended from this
root. This node sequence is used as the input to subsequent steps
in the path expression. If the context item is not a node, a
type error is
raised [err:XPTY0020]. At evaluation time, if the
root node above the context node is not a document node, a
dynamic error is
raised [err:XPDY0050].
See Bug 4855
Some incompatibilities from XPath 1.0 are undocumented; others are wrongly classified as applying only when compatibility mode is false.
1 Aug 2007: Proposed
16 Nov 2007: Corrected
20 Nov 2007: Accepted
In I.1 Incompatibilities when Compatibility Mode is true (first numbered list, second item):
Insert after the text:
| 2 |
When converting strings to numbers (either explicitly when using the |
The following:
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 2.0 with compatibility mode set to true, and cause a dynamic error when
compatibility mode is set to false.
In I.1 Incompatibilities when Compatibility Mode is true (first numbered list, fourth item):
Insert after the text:
| 4 |
The namespace axis is deprecated in 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.) |
The following:
| 5 |
In XPath 1.0, the expression |
| 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 |
In I.2 Incompatibilities when Compatibility Mode is false (first numbered list, eighth item):
Delete the text:
| 8 |
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 |
In I.2 Incompatibilities when Compatibility Mode is false (first numbered list, ninth item):
Replace the text:
| 9 |
The rules for converting strings to numbers have changed. In addition to the changes
that apply when XPath 1.0 compatibility mode is true, when compatibility mode is false the
strings |
By:
| 9 |
The rules for converting strings to numbers have changed. The implicit
conversion that occurs when passing an |
In I.2 Incompatibilities when Compatibility Mode is false (first numbered list, twelfth item):
Insert after the text:
| 12 |
In XPath 1.0, it was defined that with an expression of the form |
The following:
| 13 |
In XPath 1.0, the expression |
See Bug 4298
Spelling mistake: minimum
1 Aug 2007: Proposed
20 Nov 2007: Accepted
In I Backwards Compatibility with XPath 1.0 (Non-Normative) (first numbered list, first item):
Replace the text:
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 minumum, but some differences remain and are listed individually.
By:
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.3.4 Errors and Optimization
XP.E4
3.2 Path Expressions
XP.E3
3.10.3 Castable
XP.E5
I Backwards Compatibility with XPath 1.0 (Non-Normative)
XP.E1
I.1 Incompatibilities when Compatibility Mode is true
XP.E2
I.2 Incompatibilities when Compatibility Mode is false
XP.E2
Bug #4298: XP.E1
Bug #4446: XP.E4
Bug #4855: XP.E2
Bug #4868: XP.E3
Bug #4873: XP.E5
- (minus): XP.E2
/ (at start of path): XP.E3
// (at start of path): XP.E3
castable as: XP.E5
| (union): XP.E2