Copyright © 2007-2009 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 the XML Query Working Group. For updates see the latest version of that document.
The errata are numbered, and are listed in reverse chronological order of their date of origin. Each erratum is classified as Substantive, Editorial, or Markup. These categories are defined as follows:
Substantive: a change to the specification that may require implementations to change and that may change the outcome of a stylesheet or query.
Editorial: a clarification, correction of a textual error, or removal of an inconsistency, where the Working Group does not believe that the intent of the specification has changed. The erratum may affect implementations or user-written queries and stylesheets if the previous lack of clarity in the specification resulted in a misreading.
Markup: correction of formatting; the effect is cosmetic only.
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 the XML Query Working Group (part of the XML Activity), where there is 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/.
This is a public draft. None of the errata reported in this document have been approved by a Call for Review of Proposed Corrections or a Call for Review of an Edited Recommendation. As a consequence, they must not be considered to be normative.
The Working Group does not intend to progress these errata to normative status; instead, it intends to publish a second edition of the Recommendation incorporating these errata, and to progress the second edition to normative status.
Errata
XP.E19 Specifies that leading and trailing whitespace are stripped from a PITarget specified in a SequenceType of form processing-instruction(PITarget) before it is tested to see if it is a syntactically valid NCName.
XP.E18 Corrects the description of precedence with respect to parentheses and square brackets.
XP.E16 Clarifications on parsing leading / in XPath expressions.
XP.E15 Defines the meaning of "undefined" for Data Model properties.
XP.E14 Specifies conformance criteria for syntax extensions.
XP.E13 Allows (and encourages) the use of XML 1.0 editions newer than the Third Edition.
XP.E11 Corrects a list of examples of primitive atomic types.
XP.E10 Specifies that general comparisons cast an untyped operand to the primitive base type of the other operand rather than to the most specific type of the other operand.
XP.E9 Deletes unnecessary reference to RFC2396 from Normative References.
XP.E8 Removes references to error code FORG0001 from description of cast expression.
XP.E7 Specifies that an error results if the PITarget specified in a SequenceType of form processing-instruction(PITarget) is not a syntactically valid NCName.
XP.E6 Undocumented incompatibility when the operators <, >, <=, or >= are used to compare a number to a boolean.
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 5351
Specifies that leading and trailing whitespace are stripped from a PITarget specified
in a SequenceType of form
processing-instruction(PITarget) before it is tested to see if it is a
syntactically valid NCName.
Also makes the description of the error introduced in E12 more precise. If accepted, this supersedes E12.
17 Mar 2009: Proposed
26 Mar 2009: Accepted
In 2.5.4.2 Matching an ItemType and an Item (first bulleted list, sixth item, first paragraph):
Replace the text:
processing-instruction(N)
matches any processing-instruction node whose name (called its
"PITarget" in XML) is equal to N, where N is
an NCName.
With:
processing-instruction(N)
matches any processing-instruction node whose PITarget is equal to fn:normalize-space(N). If fn:normalize-space(N) is not in the lexical space of NCName, a type error is raised [err:XPTY0004]
In 2.5.4.2 Matching an ItemType and an Item (first bulleted list, sixth item, third paragraph):
Insert after the text:
For backward compatibility with
XPath 1.0, the PITarget of a
processing instruction may also be expressed as a
string literal, as in this example:
processing-instruction("xml-stylesheet").
The following:
In XPath 2.0, a type error is raised if, for a PITarget specified in a SequenceType of form processing-instruction(N), fn:normalize-space(N) is not in the lexical space of NCName. In XPath 1.0, this condition was not treated as an error.
See Bug 5876
Corrects the description of precedence with respect to parentheses and square brackets.
17 Mar 2009: Proposed
26 Mar 2009: Accepted
In A.4 Precedence Order (first paragraph):
Replace the text:
The grammar in A.1 EBNF normatively defines built-in precedence among the operators of XPath. These operators are summarized here to make clear the order of their precedence from lowest to highest. Operators that have a lower precedence number cannot be contained by operators with a higher precedence number. The associativity column indicates the order in which operators of equal precedence in an expression are applied.
With:
The grammar in A.1 EBNF normatively defines built-in precedence among the operators of XPath. These operators are summarized here to make clear the order of their precedence from lowest to highest. The associativity column indicates the order in which operators of equal precedence in an expression are applied.
In A.4 Precedence Order (first table, nineteenth row):
Replace the text:
| 19 | [ ], ( ), {} | left-to-right |
With:
| 19 | [ ] | left-to-right |
Insert at the end of section A.4 Precedence Order
The following:
Note:
Parentheses can be used to override the operator precedence in the usual way. Square brackets in an expression such as A[B] serve two roles: they act as an operator causing B to be evaluated once for each item in the value of A, and they act as parentheses enclosing the expression B.
See Bug 5727
Clarifications on parsing leading / in XPath expressions.
22 Feb 2009: Proposed
26 Mar 2009: Accepted
In A.1.2 Extra-grammatical Constraints (first constraint):
Replace the text:
Constraint: leading-lone-slash
A single slash may appear either as a complete path expression or as the first part of a path expression in which it is followed by a RelativePathExpr, which can take the form of a NameTest ("*" or a QName). In contexts where operators like "*", "union", etc., can occur, parsers may have difficulty distinguishing operators from NameTests. For example, without lookahead the first part of the expression "/ * 5", for example is easily taken to be a complete expression, "/ *", which has a very different interpretation (the child nodes of "/").
To reduce the need for lookahead, therefore, if the token immediately following a slash is "*" or a keyword, then the slash must be the beginning, but not the entirety, of a PathExpr (and the following token must be a NameTest, not an operator).
A single slash may be used as the left-hand argument of an
operator by parenthesizing it: (/) * 5. The expression 5 *
/, on the other hand, is legal without parentheses.
With:
Constraint: leading-lone-slash
A single slash may appear either as a complete path
expression or as the first part of a path expression in
which it is followed by a RelativePathExpr. In some cases,
the next token after the slash is insufficient to allow a
parser to distinguish these two possibilities: the
* token and keywords like union
could be either an operator or a NameTest . For
example, without lookahead the first part of the expression
/ * 5 is easily taken to be a complete
expression, / *, which has a very different
interpretation (the child nodes of /).
Therefore to reduce the need for lookahead, if the token immediately following a slash can form the start of a RelativePathExpr, then the slash must be the beginning of a PathExpr, not the entirety of it.
A single slash may be used as the left-hand argument of
an operator by parenthesizing it: (/) * 5. The
expression 5 * /, on the other hand, is legal
without parentheses.
See Bug 6287
Defines the meaning of "undefined" for Data Model properties.
22 Feb 2009: Proposed
26 Mar 2009: Accepted
In 2 Basics (third paragraph):
Replace the text:
[Definition] In the data model, a value is always a sequence. [Definition] A
sequence is an ordered collection of zero or more
items.
[Definition] An
item is either an atomic value or a node.
[Definition] An atomic
value is a value in the value space of an atomic
type, as defined in
[XML Schema]
.
[Definition] A node is an instance of one of the
node kinds defined in
[XQuery/XPath Data Model (XDM)]
.
Each node has a unique node identity, a typed value, and a string value. In addition, some nodes have a name. The typed value of a node is a sequence
of zero or more atomic values. The string value of a node is a
value of type xs:string. The name of a node is a value of type xs:QName.
With:
[Definition] In the data model, a value
is always a sequence. [Definition] A sequence is an
ordered collection of zero or more items. [Definition] An item is either an atomic value or a node. [Definition] An atomic
value is a value in the value space of an atomic
type, as defined in
[XML Schema]
. [Definition] A node is an instance of one of the
node kinds defined in
[XQuery/XPath Data Model (XDM)]
. Each node has a unique node
identity, a typed value, and a
string value. In addition, some nodes have a
name. The typed value of a node is a
sequence of zero or more atomic values. The string
value of a node is a value of type
xs:string. The name of a node is a
value of type xs:QName.
[Definition] In certain
situations a value is said to be undefined (for
example, the value of the context item, or the typed value of
an element node). This term indicates that the property in
question has no value and that any attempt to use its value
results in an error.
See Bug 6027
Specifies conformance criteria for syntax extensions.
22 Feb 2009: Proposed
26 Mar 2009: Accepted
In F Conformance (first paragraph):
Insert after the text:
XPath is intended primarily as a component that can be used by other specifications. Therefore, XPath relies on specifications that use it (such as [XPointer] and [XSLT 2.0] ) to specify conformance criteria for XPath in their respective environments. Specifications that set conformance criteria for their use of XPath must not change the syntactic or semantic definitions of XPath as given in this specification, except by subsetting and/or compatible extensions.
The following:
The specification of such a language may describe it as an extension of XPath provided that every expression that conforms to the XPath grammar behaves as described in this specification.
See Bug 5347
Allows (and encourages) the use of XML 1.0 editions newer than the Third Edition.
22 Feb 2009: Proposed
26 Mar 2009: Accepted
In E.1 Normative References (first bibliography, seventh bibliographic reference):
Replace the text:
With:
In D Implementation-Defined Items (first numbered list, sixth item):
Replace the text:
6 | Whether the implementation is based on the rules of [XML 1.0] and [XML Names] or the rules of [XML 1.1] and [XML Names 1.1] . One of these sets of rules must be applied consistently by all aspects of the implementation. |
With:
Whether the implementation is based on the rules of [XML 1.0] and [XML Names] or the rules of [XML 1.1] and [XML Names 1.1] . One of these sets of rules must be applied consistently by all aspects of the implementation. If the implementation is based on the rules of [XML 1.0] , the edition is used must be at least Third Edition; the edition used is implementation-defined, but we recommend that implementations use the latest version.
See Bug 5984
Corrects a list of examples of primitive atomic types.
10 Sep 2008: Proposed
7 Oct 2008: Accepted
In 2.5.1 Predefined Schema Types (first numbered list, fifth item, first paragraph):
Replace the text:
[Definition] xs:anyAtomicType is an atomic type that includes all atomic values (and no values that
are not atomic). Its base type is
xs:anySimpleType from which all simple types, including atomic,
list, and union types, are derived. All primitive atomic types, such as
xs:integer, xs:string, and xs:untypedAtomic, have xs:anyAtomicType as their base type.
With:
[Definition]
xs:anyAtomicType is an atomic type that includes all
atomic values (and no values that are not atomic). Its base type is
xs:anySimpleType from which all simple types, including
atomic, list, and union types, are derived. All primitive atomic types,
such as xs:decimal and xs:string,
have xs:anyAtomicType as their base type.
See Bug 5223
Specifies that general comparisons cast an untyped operand to the primitive base type of the other operand rather than to the most specific type of the other operand.
22 Jul 2008: Proposed
7 Oct 2008: Accepted
In 3.5.2 General Comparisons (starting at first numbered list, fourth item, first numbered list, second item):
Replace the text:
b | If at least one of the two atomic values is an instance of |
c | If one of the atomic values is an instance of |
With:
b | If both atomic values are instances of |
c | If exactly one of the atomic values is an instance of
Note:
The special treatment of the duration types is required to avoid
errors that may arise when comparing the primitive type
|
In 3.5.2 General Comparisons (starting at second numbered list, second item, first numbered list, first item):
Replace the text:
a | If one of the atomic values is an instance of |
b | If one of the atomic values is an instance of |
c | If one of the atomic values is an instance of |
With:
a | If both atomic values are instances of |
b | If exactly one of the atomic values is an instance of
Note:
The special treatment of the duration types is required to avoid
errors that may arise when comparing the primitive type
|
See Bug 5471
Deletes unnecessary reference to RFC2396 from Normative References. This item is never referenced in the normative text.
18 Jul 2008: Proposed
7 Oct 2008: Accepted
In E.1 Normative References (first bibliography, second bibliographic reference):
Delete the text:
See Bug 5261
Removes references to error code FORG0001 from description of cast expression. Replaces them with a reference to Functions and Operators for normative description of error behavior.
18 Jul 2008: Proposed
7 Oct 2008: Accepted
In 3.10.2 Cast (first numbered list, fourth item, first numbered list, third item):
Replace the text:
c |
|
With:
c |
|
See Bug 5351
Specifies that an error results if the PITarget specified in a SequenceType of form
processing-instruction(PITarget) is not a syntactically valid NCName.
16 Jul 2008: Proposed
7 Oct 2008: Accepted
In 2.5.4.2 Matching an ItemType and an Item (first bulleted list, sixth item, third paragraph):
Insert after the text:
For backward compatibility with
XPath 1.0, the PITarget of a
processing instruction may also be expressed as a
string literal, as in this example:
processing-instruction("xml-stylesheet").
The following:
If the specified PITarget is not a syntactically valid NCName, a type error is raised [err:XPTY0004].
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:
8 |
In XPath 2.0, a type error is raised if the PITarget specified
in a SequenceType of form
|
See Bug 5445
Undocumented incompatibility when the operators <, >, <=, or >= are used to compare a number to a boolean.
11 Mar 2008: Proposed
7 Oct 2008: Accepted
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:
7 | If one operand in a general comparison is a single atomic value of type
|
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:
With:
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.
With:
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:
With:
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].
With:
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].
With:
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 |
With:
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.
With:
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 Basics
XP.E15
2.3.4 Errors and Optimization
XP.E4
2.5.1 Predefined Schema Types
XP.E11
2.5.4.2 Matching an ItemType and an Item
XP.E7 XP.E19
3.2 Path Expressions
XP.E3
3.5.2 General Comparisons
XP.E10
3.10.2 Cast
XP.E8
3.10.3 Castable
XP.E5
A.1.2 Extra-grammatical Constraints
XP.E16
A.4 Precedence Order
XP.E18
D Implementation-Defined Items
XP.E13
E.1 Normative References
XP.E9 XP.E13
F Conformance
XP.E14
I Backwards Compatibility with XPath 1.0 (Non-Normative)
XP.E1
I.1 Incompatibilities when Compatibility Mode is true
XP.E2 XP.E6 XP.E7
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
Bug #5223: XP.E10
Bug #5261: XP.E8
Bug #5347: XP.E13
Bug #5445: XP.E6
Bug #5471: XP.E9
Bug #5727: XP.E16
Bug #5876: XP.E18
Bug #5984: XP.E11
Bug #6027: XP.E14
Bug #6287: XP.E15
- (minus): XP.E2
/ (at start of path): XP.E3
// (at start of path): XP.E3
<: XP.E6
<=: XP.E6
>: XP.E6
>=: XP.E6
| (union): XP.E2
castable as: XP.E5