Errata for XML Path Language (XPath) 2.0

31 March 2009

Latest version:
http://www.w3.org/XML/2007/qt-errata/xpath20-errata.html
Editors:
Don Chamberlin, IBM Almaden Research Center http://www.almaden.ibm.com/
Michael Kay, Saxonica http://www.saxonica.com/
Jonathan Robie, Red Hat http://www.redhat.com

Abstract

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:

Each entry contains the following information:

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/.

Status of this Document

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.

Table of Contents

  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

    Index by affected section

    Index by Bugzilla entry

    Index by operator


XP.E19 - substantive

See Bug 5351

Description

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.

History

17 Mar 2009: Proposed

26 Mar 2009: Accepted

Changes

  1. 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]

  2. 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.

XP.E18 - substantive

See Bug 5876

Description

Corrects the description of precedence with respect to parentheses and square brackets.

History

17 Mar 2009: Proposed

26 Mar 2009: Accepted

Changes

  1. 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.

  2. In A.4 Precedence Order (first table, nineteenth row):

    Replace the text:

    19[ ], ( ), {}left-to-right

    With:

    19[ ]left-to-right
  3. 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.

XP.E16 - substantive

See Bug 5727

Description

Clarifications on parsing leading / in XPath expressions.

History

22 Feb 2009: Proposed

26 Mar 2009: Accepted

Change

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.

XP.E15 - editorial

See Bug 6287

Description

Defines the meaning of "undefined" for Data Model properties.

History

22 Feb 2009: Proposed

26 Mar 2009: Accepted

Change

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.

XP.E14 - substantive

See Bug 6027

Description

Specifies conformance criteria for syntax extensions.

History

22 Feb 2009: Proposed

26 Mar 2009: Accepted

Change

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.

XP.E13 - substantive

See Bug 5347

Description

Allows (and encourages) the use of XML 1.0 editions newer than the Third Edition.

History

22 Feb 2009: Proposed

26 Mar 2009: Accepted

Changes

  1. In E.1 Normative References (first bibliography, seventh bibliographic reference):

    Replace the text:

    XML 1.0
    World Wide Web Consortium. Extensible Markup Language (XML) 1.0. (Third Edition) W3C Recommendation. See http://www.w3.org/TR/REC-xml

    With:

    XML 1.0
    World Wide Web Consortium. Extensible Markup Language (XML) 1.0. W3C Recommendation. See http://www.w3.org/TR/REC-xml. The edition of XML 1.0 must be no earlier than the Third Edition; the edition used is implementation-defined, but we recommend that implementations use the latest version.
  2. 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.

XP.E11 - editorial

See Bug 5984

Description

Corrects a list of examples of primitive atomic types.

History

10 Sep 2008: Proposed

7 Oct 2008: Accepted

Change

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.

XP.E10 - substantive

See Bug 5223

Description

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.

History

22 Jul 2008: Proposed

7 Oct 2008: Accepted

Changes

  1. 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 xs:string, or if both atomic values are instances of xs:untypedAtomic, then both atomic values are cast to the type xs:string.

    c

    If one of the atomic values is an instance of xs:untypedAtomic and the other is not an instance of xs:string, xs:untypedAtomic, or any numeric type, then the xs:untypedAtomic value is cast to the dynamic type of the other value.

    With:

    b

    If both atomic values are instances of xs:untypedAtomic, then the values are cast to the type xs:string.

    c

    If exactly one of the atomic values is an instance of xs:untypedAtomic, and the previous rule does not apply (that is, the other value is not numeric), then it is cast to a type depending on the other value's dynamic type T according to the following rules, in which V denotes the value to be cast:

    1. If T is xs:dayTimeDuration or is derived from xs:dayTimeDuration, then V is cast to xs:dayTimeDuration.

    2. If T is xs:yearMonthDuration or is derived from xs:yearMonthDuration, then V is cast to xs:yearMonthDuration.

    3. In all other cases, V is cast to the primitive base type of T.

    Note:

    The special treatment of the duration types is required to avoid errors that may arise when comparing the primitive type xs:duration with any duration type.

  2. 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 xs:untypedAtomic and the other is an instance of a numeric type, then the xs:untypedAtomic value is cast to the type xs:double.

    b

    If one of the atomic values is an instance of xs:untypedAtomic and the other is an instance of xs:untypedAtomic or xs:string, then the xs:untypedAtomic value (or values) is (are) cast to the type xs:string.

    c

    If one of the atomic values is an instance of xs:untypedAtomic and the other is not an instance of xs:string, xs:untypedAtomic, or any numeric type, then the xs:untypedAtomic value is cast to the dynamic type of the other value.

    With:

    a

    If both atomic values are instances of xs:untypedAtomic, then the values are cast to the type xs:string.

    b

    If exactly one of the atomic values is an instance of xs:untypedAtomic, it is cast to a type depending on the other value's dynamic type T according to the following rules, in which V denotes the value to be cast:

    1. If T is a numeric type or is derived from a numeric type, then V is cast to xs:double.

    2. If T is xs:dayTimeDuration or is derived from xs:dayTimeDuration, then V is cast to xs:dayTimeDuration.

    3. If T is xs:yearMonthDuration or is derived from xs:yearMonthDuration, then V is cast to xs:yearMonthDuration.

    4. In all other cases, V is cast to the primitive base type of T.

    Note:

    The special treatment of the duration types is required to avoid errors that may arise when comparing the primitive type xs:duration with any duration type.

XP.E9 - editorial

See Bug 5471

Description

Deletes unnecessary reference to RFC2396 from Normative References. This item is never referenced in the normative text.

History

18 Jul 2008: Proposed

7 Oct 2008: Accepted

Change

In E.1 Normative References (first bibliography, second bibliographic reference):

Delete the text:

RFC2396
T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax. IETF RFC 2396. See http://www.ietf.org/rfc/rfc2396.txt.

XP.E8 - editorial

See Bug 5261

Description

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.

History

18 Jul 2008: Proposed

7 Oct 2008: Accepted

Change

In 3.10.2 Cast (first numbered list, fourth item, first numbered list, third item):

Replace the text:

c

cast is supported if the target type is a non-primitive atomic type and the input type is xs:string or xs:untypedAtomic. The input value is first converted to a value in the lexical space of the target type by applying the whitespace normalization rules for the target type (as defined in [XML Schema] ); a dynamic error [err:FORG0001] is raised if the resulting lexical value does not satisfy the pattern facet of the target type. The lexical value is then converted to the value space of the target type using the schema-defined rules for the target type; a dynamic error [err:FORG0001] is raised if the resulting value does not satisfy all the facets of the target type.

With:

c

cast is supported if the target type is a non-primitive atomic type and the input type is xs:string or xs:untypedAtomic. The input value is first converted to a value in the lexical space of the target type by applying the whitespace normalization rules for the target type (as defined in [XML Schema] ). The lexical value is then converted to the value space of the target type using the schema-defined rules for the target type. If the input value fails to satisfy some facet of the target type, a dynamic error may be raised as specified in [XQuery 1.0 and XPath 2.0 Functions and Operators] .

XP.E7 - substantive

See Bug 5351

Description

Specifies that an error results if the PITarget specified in a SequenceType of form processing-instruction(PITarget) is not a syntactically valid NCName.

History

16 Jul 2008: Proposed

7 Oct 2008: Accepted

Changes

  1. 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].

  2. 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 processing-instruction(PITarget) is not a valid NCName. In XPath 1.0, this condition was not treated as an error.

XP.E6 - editorial

See Bug 5445

Description

Undocumented incompatibility when the operators <, >, <=, or >= are used to compare a number to a boolean.

History

11 Mar 2008: Proposed

7 Oct 2008: Accepted

Change

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 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 2.0 even when compatibility mode is set to true.

XP.E5 - substantive

See Bug 4873

Description

This erratum clarifies the conditions under which a castable expression may raise an error.

History

19 Sep 2007: Proposed

20 Nov 2007: Accepted

Change

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:

XP.E4 - substantive

See Bug 4446

Description

This erratum adds more details to the rules defining permissible expression rewrites for optimization and other purposes.

History

19 Sep 2007: Proposed

20 Nov 2007: Accepted

Changes

  1. 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.

  2. 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:

XP.E3 - editorial

See Bug 4868

Description

For valid syntax, parentheses need to be added to the expansion for leading "/" and leading "//" in a path expression.

History

10 Aug 2007: Proposed

20 Nov 2007: Accepted

Changes

  1. 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].

  2. 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].

XP.E2 - editorial

See Bug 4855

Description

Some incompatibilities from XPath 1.0 are undocumented; others are wrongly classified as applying only when compatibility mode is false.

History

1 Aug 2007: Proposed

16 Nov 2007: Corrected

20 Nov 2007: Accepted

Changes

  1. 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 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 2.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.

    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.

  2. 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 -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 2.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.

  3. 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 xs:float and xs:double values.

  4. 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 Infinity and -Infinity are no longer recognized as representations of positive and negative infinity. Note also that while the number function continues to convert all unrecognized strings to NaN, operations that cast a string to a number react to such strings with a dynamic error.

    With:

    9

    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.

  5. 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 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 2.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.

    The following:

    13

    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 2.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 2.0 will return the value of y, whereas XPath 1.0 returned the negation of the numeric value of y.

XP.E1 - editorial

See Bug 4298

Description

Spelling mistake: minimum

History

1 Aug 2007: Proposed

20 Nov 2007: Accepted

Change

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.


Index by affected section

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

Index by Bugzilla entry

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 #5351: XP.E7 XP.E19

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

Index by operator

- (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