View Old View New View Both View Only Previous Next

This draft contains only sections that have differences from the version that it modified.

W3C

XML Path Language (XPath) 4.0 WG Review Draft

W3C Editor's Draft 23 February 2026

This version:
https://qt4cg.org/specifications/xpath-40/
Most recent version of XPath:
https://qt4cg.org/specifications/xpath-40/
Most recent Recommendation of XPath:
https://www.w3.org/TR/2017/REC-xpath-31-20170321/
Editor:
Michael Kay, Saxonica <mike@saxonica.com>

Please check the errata for any errors or issues reported since publication.

See also translations.

This document is also available in these non-normative formats: XML.


Abstract

XPath 4.0 is an expression language that allows the processing of values conforming to the data model defined in [XQuery and XPath Data Model (XDM) 4.0]. The name of the language derives from its most distinctive feature, the path expression, which provides a means of hierarchic addressing of the nodes in an XML tree. As well as modeling the tree structure of XML, the data model also includes atomic items, function items, maps, arrays, and sequences. This version of XPath supports JSON as well as XML, and adds many new functions in [XQuery and XPath Functions and Operators 4.0].

XPath 4.0 is a superset of XPath 3.1. A detailed list of changes made since XPath 3.1 can be found in I Change Log.

Status of this Document

This is a draft prepared by the QT4CG (officially registered in W3C as the XSLT Extensions Community Group). Comments are invited.

Dedication

The publications of this community group are dedicated to our co-chair, Michael Sperberg-McQueen (1954–2024).

Michael was central to the development of XML and many related technologies. He brought a polymathic breadth of knowledge and experience to everything he did. This, combined with his indefatigable curiosity and appetite for learning, made him an invaluable contributor to our project, along with many others. We have lost a brilliant thinker, a patient teacher, and a loyal friend.


4 Expressions

This section discusses each of the basic kinds of expression. Each kind of expression has a name such as PathExpr, which is introduced on the left side of the grammar production that defines the expression. Since XPath 4.0 is a composable language, each kind of expression is defined in terms of other expressions whose operators have a higher precedence. In this way, the precedence of operators is represented explicitly in the grammar.

The order in which expressions are discussed in this document does not reflect the order of operator precedence. In general, this document introduces the simplest kinds of expressions first, followed by more complex expressions. For the complete grammar, see Appendix [A XPath 4.0 Grammar].

The highest-level symbol in the XPath grammar is XPath.

XPath::=Expr
Expr::=(ExprSingle ++ ",")
ExprSingle::=ForExpr
| LetExpr
| QuantifiedExpr
| IfExpr
| OrExpr
ExprSingle::=ForExpr
| LetExpr
| QuantifiedExpr
| IfExpr
| OrExpr
ForExpr::=ForClauseForLetReturn
LetExpr::=LetClauseForLetReturn
QuantifiedExpr::=("some" | "every") (QuantifierBinding ++ ",") "satisfies" ExprSingle
IfExpr::="if" "(" Expr ")" (UnbracedActions | BracedAction)
OrExpr::=AndExpr ("or" AndExpr)*

The XPath 4.0 operator that has lowest precedence is the comma operator, which is used to combine two operands to form a sequence. As shown in the grammar, a general expression (Expr) can consist of multiple ExprSingle operands, separated by commas.

The name ExprSingle denotes an expression that does not contain a top-level comma operator (despite its name, an ExprSingle may evaluate to a sequence containing more than one item.)

The symbol ExprSingle is used in various places in the grammar where an expression is not allowed to contain a top-level comma. For example, each of the arguments of a function call must be a ExprSingle, because commas are used to separate the arguments of a function call.

After the comma, the expressions that have next lowest precedence are ForExpr, LetExpr, QuantifiedExpr, IfExpr, and OrExpr. Each of these expressions is described in a separate section of this document.

4.12 For and Let Expressions

XPath provides two closely-related expressions, called For and Let expressions, that can be used to bind variables to values. These are described in the following sections.

4.12.1 For Expressions

Changes in 4.0  

  1. A for member clause is added to FLWOR expressions to allow iteration over an array.  [Issue 49 PR 344 10 February 2023]

  2. Multiple for and let clauses can be combined in an expression without an intervening return keyword.   [Issue 22 PR 28 18 December 2020]

  3. A for key/value clause is added to FLWOR expressions to allow iteration over maps.  [Issue 31 PR 1249 1 June 2024]

  4. A positional variable can be defined in a for expression.   [Issue 231 PR 1131 1 April 2024]

  5. The type of a variable used in a for expression can be declared.   [Issue 796 PR 1131 1 April 2024]

XPath provides an iteration facility called a for expression. It can be used to iterate over the items of a sequence, the members of an array, or the entries in a map.

ForExpr::=ForClauseForLetReturn
ForClause::="for" (ForBinding ++ ",")
ForBinding::=ForItemBinding | ForMemberBinding | ForEntryBinding
ForItemBinding::=VarNameAndTypePositionalVar? "in" ExprSingle
VarNameAndType::="$" EQNameTypeDeclaration?
EQName::=QName | URIQualifiedName
TypeDeclaration::="as" SequenceType
PositionalVar::="at" VarName
VarName::="$" EQName
ExprSingle::=ForExpr
| LetExpr
| QuantifiedExpr
| IfExpr
| OrExpr
ForMemberBinding::="member" VarNameAndTypePositionalVar? "in" ExprSingle
ForEntryBinding::=((ForEntryKeyBindingForEntryValueBinding?) | ForEntryValueBinding) PositionalVar? "in" ExprSingle
ForEntryKeyBinding::="key" VarNameAndType
ForEntryValueBinding::="value" VarNameAndType
ForLetReturn::=ForExpr | LetExpr | ("return" ExprSingle)
LetExpr::=LetClauseForLetReturn

A for expression is evaluated as follows:

  1. If the ForClause includes multiple ForBindings with a comma separator, the forexpression is first expanded to a set of nested for expressions, each of which contains a single ForBinding. More specifically, every separating comma is replaced by for.

    Example:

    The expression:

    for $x in X, $y in Y return $x + $y

    is expanded to:

    for $x in X for $y in Y return $x + $y
  2. Having performed this expansion, variables bound in the ForClause are called the range variables, the variable named in the PositionalVar (if present) is called the position variable, the expression that follows the in keyword is called the binding expression, and the expression in the ForLetReturn part (that is, the following LetExpr or ForExpr, or the ExprSingle that follows the return keyword) is called the return expression.

    [Definition: The result of evaluating the binding expression in a for expression is called the binding collection ].

  3. If a position variable is declared, its type is implicitly xs:integer. Its name (as an expanded QName) must be different from the name of a range variable declared in the same ForBinding. [err:XQST0089].

  4. When a ForItemBinding is used (that is, when none of the keywords member, key, or value is used), the expression iterates over the items in a sequence:

    1. If a TypeDeclaration is present then each item in the binding collection is converted to the specified type by applying the coercion rules.

    2. The return expression is evaluated once for each item in the binding collection, with a dynamic context in which the range variable is bound to that item, and the position variable (if present) is bound to the one-based position of that item in the binding collection, as an instance of type xs:integer.

    3. The result of the for expression is the sequence concatenation of the results of the successive evaluations of the return expression.

  5. When the member keyword is present:

    1. The value of the binding collection must be a single array. Otherwise, a type error is raised: [err:XPTY0141].

    2. If a TypeDeclaration is present then each member of the binding collection array is converted to the specified type by applying the coercion rules. (Recall that this can be any sequence, not necessarily a single item).

    3. The result of the single-variable for member expression is obtained by evaluating the return expression once for each member of that array, with the range variable bound to that member

    4. The return expression is evaluated once for each member of the binding collection array, with a dynamic context in which the range variable is bound to that member, and the position variable (if present) is bound to the one-based position of that member in the binding collection.

    5. The result of the for expression is the sequence concatenation of the results of the successive evaluations of the return expression.

      Note that the result is a sequence, not an array.

  6. When the key and/or value keywords are present:

    1. The value of the binding collection must be a single map. Otherwise, a type error is raised: [err:XPTY0141]. The map is treated as a sequence of key/value pairs, in implementation dependent order.

    2. If the key keyword is present, then the corresponding variable is bound to the key part of the key/value pair.

    3. If the value keyword is present, then the corresponding variable is bound to the value part of the key/value pair.

    4. If both the key and value keywords are present, then the corresponding variables must have distinct names. [err:XQST0089].

    5. If a TypeDeclaration is present for the key, then each key is converted to the specified type by applying the coercion rules.

    6. If a TypeDeclaration is present for the value, then each value is converted to the specified type by applying the coercion rules.

    7. The result of the single-variable for key/value expression is obtained by evaluating the return expression once for each entry in the map, with the range variables bound to that entry as described.

    8. The return expression is evaluated once for each entry of the binding collection map, with a dynamic context in which the keyrange variable (if present) is bound to the key part of that entry, the valuerange variable (if present) is bound to the value part of that entry, and the position variable (if present) is bound to the one-based position of that entry in the implementation dependent ordering of the binding collection.

    9. The result of the for expression is the sequence concatenation of the results of the successive evaluations of the return expression.

      Note that the result is a sequence, not a map.

The following example illustrates the use of a for expression in restructuring an input document. The example is based on the following input:

<bib>
  <book>
    <title>TCP/IP Illustrated</title>
    <author>Stevens</author>
    <publisher>Addison-Wesley</publisher>
  </book>
  <book>
    <title>Advanced Programming in the Unix Environment</title>
    <author>Stevens</author>
    <publisher>Addison-Wesley</publisher>
  </book>
  <book>
    <title>Data on the Web</title>
    <author>Abiteboul</author>
    <author>Buneman</author>
    <author>Suciu</author>
  </book>
</bib>

The following example transforms the input document into a list in which each author’s name appears only once, followed by a list of titles of books written by that author. This example assumes that the context value is the bib element in the input document.

for $a in distinct-values(book/author)
return ((book/author[. = $a])[1], book[author = $a]/title)

The result of the above expression consists of the following sequence of elements. The titles of books written by a given author are listed after the name of the author. The ordering of author elements in the result is implementation-dependent due to the semantics of the fn:distinct-values function.

<author>Stevens</author>
<title>TCP/IP Illustrated</title>
<title>Advanced Programming in the Unix environment</title>
<author>Abiteboul</author>
<title>Data on the Web</title>
<author>Buneman</author>
<title>Data on the Web</title>
<author>Suciu</author>
<title>Data on the Web</title>

The following example illustrates a for expression containing more than one variable:

for $i in (10, 20),
    $j in (1, 2)
return ($i + $j)

The result of the above expression, expressed as a sequence of numbers, is as follows: 11, 12, 21, 22

The scope of a variable bound in a for expression is the return expression. The scope does not include the expression to which the variable is bound. The following example illustrates how a variable binding may reference another variable bound earlier in the same for expression:

for $x in $z, $y in f($x)
return g($x, $y)

The following example illustrates processing of an array.

for member $map in parse-json('[{ "x": 1, "y": 2 }, { "x": 10, "y": 20 }]') 
return $map ! (?x + ?y)

The result is the sequence (3, 30).

The following example illustrates processing of a map.

for key $key value $value in { "x": 1, "y": 2, "z: 3 }
return `{$key}={$value}`

The result is the sequence ("x=1", "y=2", "z=3") (but not necessarily in that order).

Note:

The focus for evaluation of the return clause of a for expression is the same as the focus for evaluation of the for expression itself. The following example, which attempts to find the total value of a set of order-items, is therefore incorrect:

sum(for $i in order-item return @price * @qty)

Instead, the expression must be written to use the variable bound in the for clause:

sum(for $i in order-item return $i!(@price * @qty))

Note:

XPath 4.0 allows the format:

for $order in //orders
for $line in $order/order-line
return $line/value

primarily because it is familiar to XQuery users, some of whom may regard it as more readable than the XPath 3.1 alternative which uses a comma in place of the second for.

4.12.2 Let Expressions

Changes in 4.0  

  1. Multiple for and let clauses can be combined in an expression without an intervening return keyword.   [Issue 22 PR 28 18 December 2020]

  2. The type of a variable used in a let expression can be declared.   [Issue 796 PR 1131 1 April 2024]

  3. Sequences, arrays, and maps can be destructured in a let expression to extract their components into multiple variables.   [Issue 37 PR 19422055 17 June 2025]

XPath allows a variable to be declared and bound to a value using a let expression.

LetExpr::=LetClauseForLetReturn
LetClause::="let" (LetBinding ++ ",")
LetBinding::=LetValueBinding | LetSequenceBinding | LetArrayBinding | LetMapBinding
LetValueBinding::=VarNameAndType ":=" ExprSingle
VarNameAndType::="$" EQNameTypeDeclaration?
EQName::=QName | URIQualifiedName
TypeDeclaration::="as" SequenceType
ExprSingle::=ForExpr
| LetExpr
| QuantifiedExpr
| IfExpr
| OrExpr
LetSequenceBinding::="$" "(" (VarNameAndType ++ ",") ")" TypeDeclaration? ":=" ExprSingle
SequenceType::=("empty-sequence" "(" ")")
| (ItemTypeOccurrenceIndicator?)
LetArrayBinding::="$" "[" (VarNameAndType ++ ",") "]" TypeDeclaration? ":=" ExprSingle
LetMapBinding::="$" "{" (VarNameAndType ++ ",") "}" TypeDeclaration? ":=" ExprSingle
ForLetReturn::=ForExpr | LetExpr | ("return" ExprSingle)
ForExpr::=ForClauseForLetReturn

A let expression is evaluated as follows:

  1. If the let expression uses multiple variables, it is first expanded to a set of nested let expressions, each of which uses only one variable. Specifically, any separating comma is replaced by let.

    Example:

    The expression:

    let $x := 4, $y := 3 return $x + $y

    is expanded to:

    let $x := 4 let $y := 3 return $x + $y
  2. In a LetValueBinding such as let $V as T := EXPR:

    1. The variable V is called the range variable.

    2. The sequence type T is called the declared type. If there is no declared type, then item()* is assumed.

    3. The expression EXPR is evaluated, and its value is converted to the declared type by applying the coercion rules. The resulting value is called the binding sequence.

  3. In a LetSequenceBinding such as let $( $A1 as T1, $A2 as T2, ... , $An as Tn ) as ST := EXPR:

    1. The sequence type ST is called the declared sequence type. If there is no declared sequence type, then item()* is assumed.

    2. The expression EXPR is evaluated, and its value is converted to the declared sequence type ST by applying the coercion rules. Call the resulting (coerced) value V.

    3. Each variable Ai (for i in 1 to n) is effectively replaced by a LetValueBinding of the form let Ai as Ti := items-at(V, i). That is, a range variable named Ai is declared, whose binding sequence is the item V[ i ], after coercion to the type Ti if specified. If Ti is absent, no further coercion takes place (the default is effectively item()?).

      Note:

      If i exceeds the length of the sequence V, then Ai is bound to an empty sequence. This will cause a type error if type Ti does not permit an empty sequence.

      Note:

      It is permissible to bind several variables with the same name; all but the last are shadowedoccluded. A useful convention is therefore to bind items in the sequence that are of no interest to the variable $_: for example let $( $_, $_, $x ) := EXPR effectively binds $x to the third item in the sequence and causes the first two items to be ignored.

      Example:

      The expression:

      let $( $a, $b as xs:integer, $local:c ) := (2, 4, 6)
      return $a + $b + $local:c

      is expanded to:

      let $temp := (2, 4, 6)
      let $a := fn:items-at($temp, 1)
      let $b as xs:integer := fn:items-at($temp, 2)
      let $local:c := fn:items-at($temp, 3)
      return $a + $b + $local:c

      where $temp is some variable name that is otherwise unused.

       

      Example:

      Consider the element $E := <e A="p q r" B="x y z"/>, where $E has been validated against a schema that defines both attributes A and B as being lists of strings.

      Then the expression:

      let $( $a as xs:string*, $b as xs:string* ) := $E/(@A, @B)

      binds $a to the sequence ("p", "q", "r") and $b to the sequence ("x", "y", "z"). The evaluation of the expression $E/(@A, @B) returns a sequence of two attribute nodes; the value of $a is formed by atomizing the first of these nodes, while $b is formed by atomizing the second.

  4. In a LetArrayBinding such as let $[ $A1 as T1, $A2 as T2, ... , $An as Tn ] as AT := EXPR:

    1. The sequence type AT is called the declared array type. If there is no declared array type, then array(*) is assumed.

    2. The expression EXPR is evaluated, and its value is converted to the declared array type AT by applying the coercion rules. A type error [err:XPTY0004] is raised if the result is not a singleton array. Call the resulting (coerced) value V.

    3. Each variable Ai (for i in 1 to n) is effectively replaced by a LetValueBinding of the form let Ai as Ti := array:get(V, i, ()). That is, a range variable named Ai is declared, whose binding sequence is the array member V ? i, after coercion to the type Ti if specified. If Ti is absent, no further coercion takes place (the default is effectively item()*).

      Note:

      If i exceeds the length of the array V, then Ai is bound to an empty sequence. This will cause a type error if type Ti does not permit an empty sequence.

      Note:

      It is permissible to bind several variables with the same name; all but the last are shadowedoccluded. A useful convention is therefore to bind items in the sequence that are of no interest to the variable $_: for example let $( $_, $_, $x ) := EXPR effectively binds $x to the third item in the sequence and causes the first two items to be ignored.

      Example:

      The expression:

      let $[ $a, $b as xs:integer, $local:c ] := [ 2, 4, 6 ]
      return $a + $b + $local:c

      is expanded to:

      let $temp := [ 2, 4, 6 ]
      let $a := array:get($temp, 1, ())
      let $b as xs:integer := array:get($temp, 2, ())
      let $local:c := array:get($temp, 3, ())
      return $a + $b + $local:c

      where $temp is some variable name that is otherwise unused.

  5. In a LetMapBinding such as let ${ $A1 as T1, $A2 as T2, ... , $An as Tn } as MT := EXPR:

    1. The sequence type MT is called the declared map type. If there is no declared map type, then map(*) is assumed.

    2. The expression EXPR is evaluated, and its value is converted to the declared map type MT by applying the coercion rules. A type error [err:XPTY0004] is raised if the result is not a singleton map. Call the resulting (coerced) value V.

    3. Each variable Ai (for i in 1 to n) is effectively replaced by a LetValueBinding of the form let Ai as Ti := map:get(V, "Ni", ()), where Ni is the local part of the name of the variable Ai. That is, a range variable named Ai is declared, whose binding sequence is the value of the map entry in V whose key is an xs:string (or xs:anyURI or xs:untypedAtomic) equal to the local part of the variable name, after coercion to the type Ti if specified. If Ti is absent, no further coercion takes place (the default is effectively item()*).

      Note:

      If there is no entry in the map with a key corresponding to the variable name, then the variable Ai is bound to an empty sequence. This will cause a type error if type Ti does not permit an empty sequence.

      Note:

      It is not possible to use this mechanism to bind variables to values in a map unless the keys in the map are strings in the form of NCNames.

      Example:

      The expression:

      let ${ $a, $b as xs:integer, $local:c } := { "a": 2, "b": 4, "c": 6, "d": 8 }
      return $a + $b + $local:c

      is expanded to:

      let $temp := { "a": 2, "b": 4, "c": 6 }
      let $a := map:get($temp, "a", ())
      let $b as xs:integer := map:get($temp, "b", ())
      let $local:c := map:get($temp, "c", ())
      return $a + $b + $local:c

      where $temp is some variable name that is otherwise unused.

  6. The expression in the ForLetReturn part (that is, the following LetExpr or ForExpr, or the ExprSingle that follows the return keyword) is called the return expression. The result of the let expression is obtained by evaluating the return expression with a dynamic context in which each range variable is bound to the corresponding binding sequence.

The scope of a variable bound in a let expression is the return expression. The scope does not include the expression to which the variable is bound. The following example illustrates how a variable binding may reference another variable bound earlier in the same let expression:

let $x := doc('a.xml')/*, $y := $x//*
return $y[@value gt $x/@min]

Note:

It is not required that the variables should have distinct names. It is permitted, for example, to write:

let $x := "[A fine romance]"
let $x := substring-after($x, "[")
let $x := substring-before($x, "]")
return upper-case($x)

which returns the result "A FINE ROMANCE". Note that this expression declares three separate variables which happen to have the same name; it should not be read as declaring a single variable and binding it successively to different values.

I Change Log (Non-Normative)

  1. Use the arrows to browse significant changes since the 3.1 version of this specification.

    See 1 Introduction

  2. Sections with significant changes are marked Δ in the table of contents.

    See 1 Introduction

  3. Setting the default namespace for elements and types to the special value ##any causes an unprefixed element name to act as a wildcard, matching by local name regardless of namespace.

    See 3.2.7.2 Element Types

  4. The terms FunctionType, ArrayType, MapType, and RecordType replace FunctionTest, ArrayTest, MapTest, and RecordTest, with no change in meaning.

    See 3.2.8.1 Function Types

  5. Record types are added as a new kind of ItemType, constraining the value space of maps.

    See 3.2.8.3 Record Types

  6. Function coercion now allows a function with arity N to be supplied where a function of arity greater than N is expected. For example this allows the function true#0 to be supplied where a predicate function is required.

    See 3.4.4 Function Coercion

  7. PR 1817 1853 

    An inline function may be annotated as a %method, giving it access to its containing map.

    See 4.5.6 Inline Function Expressions

    See 4.5.6.1 Methods

    See 4.13.3 Lookup Expressions

  8. The symbols × and ÷ can be used for multiplication and division.

    See 4.8 Arithmetic Expressions

  9. The rules for value comparisons when comparing values of different types (for example, decimal and double) have changed to be transitive. A decimal value is no longer converted to double, instead the double is converted to a decimal without loss of precision. This may affect compatibility in edge cases involving comparison of values that are numerically very close.

    See 4.10.1 Value Comparisons

  10. Operators such as < and > can use the full-width forms and to avoid the need for XML escaping.

    See 4.10.2 General Comparisons

  11. The lookup operator ? can now be followed by a string literal, for cases where map keys are strings other than NCNames. It can also be followed by a variable reference.

    See 4.13.3 Lookup Expressions

  12. PR 1864 1877 

    The key specifier can reference an item type or sequence type, to select values of that type only. This is especially useful when processing trees of maps and arrays, as encountered when processing JSON input.

    See 4.13.3 Lookup Expressions

  13. PR 1763 1830 

    The syntax on the right-hand side of an arrow operator has been relaxed; a dynamic function call no longer needs to start with a variable reference or a parenthesized expression, it can also be (for example) an inline function expression or a map or array constructor.

    See 4.20 Arrow Expressions

  14. The arrow operator => is now complemented by a “mapping arrow” operator =!> which applies the supplied function to each item in the input sequence independently.

    See 4.20.2 Mapping Arrow Expressions

  15. PR 1023 1128 

    It has been clarified that function coercion applies even when the supplied function item matches the required function type. This is to ensure that arguments supplied when calling the function are checked against the signature of the required function type, which might be stricter than the signature of the supplied function item.

    See 3.4.4 Function Coercion

  16. A dynamic function call can now be applied to a sequence of functions, and in particular to an empty sequence. This makes it easier to chain a sequence of calls.

    See 4.5.3.1 Evaluating Dynamic Function Calls

  17. The syntax document-node(N), where N is a NameTestUnion, is introduced as an abbreviation for document-node(element(N)). For example, document-node(*) matches any well-formed XML document (as distinct from a document fragment).

    See 3.2.7 Node Types

  18. QName literals are new in 4.0.

    See 4.2.1.3 QName Literals

  19. PR 28 

    Multiple for and let clauses can be combined in an expression without an intervening return keyword.

    See 4.12.1 For Expressions

    See 4.12.2 Let Expressions

  20. PR 159 

    Keyword arguments are allowed on static function calls, as well as positional arguments.

    See 4.5.1.1 Static Function Call Syntax

  21. PR 202 

    The presentation of the rules for the subtype relationship between sequence types and item types has been substantially rewritten to improve clarity; no change to the semantics is intended.

    See 3.3 Subtype Relationships

  22. PR 230 

    The rules for “errors and optimization” have been tightened up to disallow many cases of optimizations that alter error behavior. In particular there are restrictions on reordering the operands of and and or, and of predicates in filter expressions, in a way that might allow the processor to raise dynamic errors that the author intended to prevent.

    See 2.4.5 Guarded Expressions

  23. PR 254 

    The term "function conversion rules" used in 3.1 has been replaced by the term "coercion rules".

    See 3.4 Coercion Rules

    The coercion rules allow “relabeling” of a supplied atomic item where the required type is a derived atomic type: for example, it is now permitted to supply the value 3 when calling a function that expects an instance of xs:positiveInteger.

    See 3.4 Coercion Rules

  24. PR 284 

    Alternative syntax for conditional expressions is available: if (condition) { X }.

    See 4.14 Conditional Expressions

  25. PR 286 

    Element and attribute tests can include alternative names: element(chapter|section), attribute(role|class).

    See 3.2.7 Node Types

    The NodeTest in an AxisStep now allows alternatives: ancestor::(section|appendix)

    See 3.2.7 Node Types

    Element and attribute tests of the form element(N) and attribute(N) now allow N to be any NameTest, including a wildcard.

    See 3.2.7.2 Element Types

    See 3.2.7.3 Attribute Types

  26. PR 324 

    String templates provide a new way of constructing strings: for example `{$greeting}, {$planet}!` is equivalent to $greeting || ', ' || $planet || '!'

    See 4.9.2 String Templates

  27. PR 326 

    Support for higher-order functions is now a mandatory feature (in 3.1 it was optional).

    See 5 Conformance

  28. PR 344 

    A for member clause is added to FLWOR expressions to allow iteration over an array.

    See 4.12.1 For Expressions

  29. PR 368 

    The concept of the context item has been generalized, so it is now a context value. That is, it is no longer constrained to be a single item.

    See 2.2.2 Dynamic Context

  30. PR 433 

    Numeric literals can now be written in hexadecimal or binary notation; and underscores can be included for readability.

    See 4.2.1.1 Numeric Literals

  31. PR 519 

    The rules for tokenization have been largely rewritten. In some cases the revised specification may affect edge cases that were handled in different ways by different 3.1 processors, which could lead to incompatible behavior.

    See A.3 Lexical structure

  32. PR 521 

    New abbreviated syntax is introduced (focus function) for simple inline functions taking a single argument. An example is fn { ../@code }

    See 4.5.6 Inline Function Expressions

  33. PR 603 

    The rules for reporting type errors during static analysis have been changed so that a processor has more freedom to report errors in respect of constructs that are evidently wrong, such as @price/@value, even though dynamic evaluation is defined to return an empty sequence rather than an error.

    See 2.4.6 Implausible Expressions

    See 4.6.4.3 Implausible Axis Steps

  34. PR 606 

    Element and attribute tests of the form element(A|B) and attribute(A|B) are now allowed.

    See 3.2.7.2 Element Types

    See 3.2.7.3 Attribute Types

  35. PR 691 

    Enumeration types are added as a new kind of ItemType, constraining the value space of strings.

    See 3.2.6 Enumeration Types

  36. PR 728 

    The syntax record(*) is allowed; it matches any map.

    See 3.2.8.3 Record Types

  37. PR 815 

    The coercion rules now allow conversion in either direction between xs:hexBinary and xs:base64Binary.

    See 3.4 Coercion Rules

  38. PR 837 

    A deep lookup operator ?? is provided for searching trees of maps and arrays.

    See 4.13.3 Lookup Expressions

  39. PR 911 

    The coercion rules now allow any numeric type to be implicitly converted to any other, for example an xs:double is accepted where the required type is xs:double.

    See 3.4 Coercion Rules

  40. PR 996 

    The value of a predicate in a filter expression can now be a sequence of integers.

    See 4.4 Filter Expressions

  41. PR 1031 

    An otherwise operator is introduced: A otherwise B returns the value of A, unless it is an empty sequence, in which case it returns the value of B.

    See 4.15 Otherwise Expressions

  42. PR 1071 

    In map constructors, the keyword map is now optional, so map { 0: false(), 1: true() } can now be written { 0: false(), 1: true() }, provided it is used in a context where this creates no ambiguity.

    See 4.13.1.1 Map Constructors

  43. PR 1125 

    Lookup expressions can now take a modifier (such as keys, values, or pairs) enabling them to return structured results rather than a flattened sequence.

    See 4.13.3 Lookup Expressions

  44. PR 1131 

    A positional variable can be defined in a for expression.

    See 4.12.1 For Expressions

    The type of a variable used in a for expression can be declared.

    See 4.12.1 For Expressions

    The type of a variable used in a let expression can be declared.

    See 4.12.2 Let Expressions

  45. PR 1132 

    Choice item types (an item type allowing a set of alternative item types) are introduced.

    See 3.2.5 Choice Item Types

  46. PR 1163 

    Filter expressions for maps and arrays are introduced.

    See 4.13.4 Filter Expressions for Maps and Arrays

  47. PR 1181 

    The default namespace for elements and types can be set to the value ##any, allowing unprefixed names in axis steps to match elements with a given local name in any namespace.

    See 2.2.1 Static Context

    If the default namespace for elements and types has the special value ##any, then an unprefixed name in a NameTest acts as a wildcard, matching names in any namespace or none.

    See 4.6.4.2 Node Tests

  48. PR 1197 

    The keyword fn is allowed as a synonym for function in function types, to align with changes to inline function declarations.

    See 3.2.8.1 Function Types

    In inline function expressions, the keyword function may be abbreviated as fn.

    See 4.5.6 Inline Function Expressions

  49. PR 1212 

    XPath 3.0 included empty-sequence and item as reserved function names, and XPath 3.1 added map and array. This was unnecessary since these names never appear followed by a left parenthesis at the start of an expression. They have therefore been removed from the list. New keywords introducing item types, such as record and enum, have not been included in the list.

    See A.4 Reserved Function Names

  50. PR 1217 

    Predicates in filter expressions for maps and arrays can now be numeric.

    See 4.13.4 Filter Expressions for Maps and Arrays

  51. PR 1249 

    A for key/value clause is added to FLWOR expressions to allow iteration over maps.

    See 4.12.1 For Expressions

  52. PR 1250 

    Several decimal format properties, including minus sign, exponent separator, percent, and per-mille, can now be rendered as arbitrary strings rather than being confined to a single character.

    See 2.2.1.2 Decimal Formats

  53. PR 1265 

    The rules regarding the document-uri property of nodes returned by the fn:collection function have been relaxed.

    See 2.2.2 Dynamic Context

  54. PR 1344 

    Parts of the static context that were there purely to assist in static typing, such as the statically known documents, were no longer referenced and have therefore been dropped.

    See 2.2.1 Static Context

    The static typing option has been dropped.

    See 2.3 Processing Model

    The static typing feature has been dropped.

    See 5 Conformance

  55. PR 1361 

    The term atomic value has been replaced by atomic item.

    See 2.1.2 Values

  56. PR 1384 

    If a type declaration is present, the supplied values in the input sequence are now coerced to the required type. Type declarations are now permitted in XPath as well as XQuery.

    See 4.16 Quantified Expressions

  57. PR 1496 

    The context value static type, which was there purely to assist in static typing, has been dropped.

    See 2.2.1 Static Context

  58. PR 1498 

    The EBNF operators ++ and ** have been introduced, for more concise representation of sequences using a character such as "," as a separator. The notation is borrowed from Invisible XML.

    See 2.1 Terminology

    The EBNF notation has been extended to allow the constructs (A ++ ",") (one or more occurrences of A, comma-separated, and (A ** ",") (zero or more occurrences of A, comma-separated.

    See 2.1.1 Grammar Notation

    The EBNF operators ++ and ** have been introduced, for more concise representation of sequences using a character such as "," as a separator. The notation is borrowed from Invisible XML.

    See A.1 EBNF

    See A.1.1 Notation

  59. PR 1501 

    The coercion rules now apply recursively to the members of an array and the entries in a map.

    See 3.4 Coercion Rules

  60. PR 1532 

    Four new axes have been defined: preceding-or-self, preceding-sibling-or-self, following-or-self, and following-sibling-or-self.

    See 4.6.4.1 Axes

  61. PR 1577 

    The syntax record() is allowed; the only thing it matches is an empty map.

    See 3.2.8.3 Record Types

  62. PR 1686 

    With the pipeline operator ->, the result of an expression can be bound to the context value before evaluating another expression.

    See 4.18 Pipeline operator

  63. PR 1696 

    Parameter names may be included in a function signature; they are purely documentary.

    See 3.2.8.1 Function Types

  64. PR 1703 

    Ordered maps are introduced.

    See 4.13.1 Maps

    The order of key-value pairs in the map constructor is now retained in the constructed map.

    See 4.13.1.1 Map Constructors

  65. PR 1874 

    The coercion rules now reorder the entries in a map when the required type is a record type.

    See 3.4 Coercion Rules

  66. PR 1898 

    The rules for subtyping of document node types have been refined.

    See 3.3.2.4.2 Subtyping Nodes: Document Nodes

  67. PR 1942 

    Sequences, arrays, and maps can be destructured in a let expression to extract their components into multiple variables.

    See 4.12.2 Let Expressions

  68. PR 1991 

    Named record types used in the signatures of built-in functions are now available as standard in the static context.

    See 2.2.1 Static Context

  69. PR 2026 

    The module feature is no longer an optional feature; processing of library modules is now required.

    See 5 Conformance

  70. PR 2055 

    Sequences, arrays, and maps can be destructured in a let expression to extract their components into multiple variables.

    See 4.12.2 Let Expressions