XML Path Language (XPath) 4.0 WG Review Draft

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

Functions in XPath 4.0 arise in two ways:

A function definition contains information about a family of functions with the same name and a defined arity range. These functions are in most cases known statically (they appear in the statically known function definitions), but there may be further function definitions that are known only dynamically (appearing in the dynamically known function definitions).
Function items are XDM items that can be called using a dynamic function call. They are values that can be bound to variables, passed as arguments, returned as function results, and generally manipulated in the same way as other XDM values.

The functions defined by a statically known function definition can be invoked using a static function call. Function items corresponding to these definitions can also be obtained, as dynamic values, by evaluating a named function reference. Function items can also be obtained using the fn:function-lookup function: in this case the function name and arity do not need to be known statically, and the function definition need not be present in the static context, so long as it is in the dynamic context.

Static and dynamic function calls are described in the following sections.

4.5.6 Inline Function Expressions

Changes in 4.0 ⬇ ⬆

In inline function expressions, the keyword function may be abbreviated as fn. [Issue 1192 PR 1197 21 May 2024]
New abbreviated syntax is introduced (focus function) for simple inline functions taking a single argument. An example is fn { ../@code } [Issue 503 PR 521 30 May 2023]
An inline function may be annotated as a %method, giving it access to its containing map. [Issues 1800 1845 PRs 1817 1853 4 March 2025]
An inline function may be annotated as a %method, giving it access to its containing map. [Issues 1800 1845 PRs 1817 1853 4 March 2025]

`InlineFunctionExpr`	::=	`MethodAnnotation* ("function" \| "fn") FunctionSignature? FunctionBody`
`MethodAnnotation`	::=	`"%method"`
`FunctionSignature`	::=	`"(" ParamList ")" TypeDeclaration?`
`ParamList`	::=	`(VarNameAndType ** ",")`
`VarNameAndType`	::=	`"$" EQNameTypeDeclaration?`
`EQName`	::=	`QName \| URIQualifiedName`
`TypeDeclaration`	::=	`"as" SequenceType`
`SequenceType`	::=	`("empty-sequence" "(" ")") \| (ItemTypeOccurrenceIndicator?)`
`FunctionBody`	::=	`EnclosedExpr`
`EnclosedExpr`	::=	`"{" Expr? "}"`

[Definition: An inline function expression, when evaluated, creates an anonymous function defined directly in the inline function expression.] An inline function expression specifies the names and SequenceTypes of the parameters to the function, the SequenceType of the result, and the body of the function.

An inline function expression whose FunctionSignature is omitted is known as a focus function. Focus functions are described in 4.5.6.2 Focus Functions.

[Definition: An anonymous function is a function item with no name. Anonymous functions may be created, for example, by evaluating an inline function expression or by partial function application.]

The keywords function and fn are synonymous.

The syntax allows the names and types of the function argument to be declared, along with the type of the result:

function($x as xs:integer, $y as xs:integer) as xs:integer { $x + $y }

The types can be omitted, and the keyword can be abbreviated:

fn($x, $y) { $x + $y }

A zero-arity function can be written as, for example, fn() { current-date() }.

If a function parameter is declared using a name but no type, its default type is item()*. If the result type is omitted, its default result type is item()*.

The parameters of an inline function expression are considered to be variables whose scope is the function body. It is a static error [err:XQST0039] for an inline function expression to have more than one parameter with the same name.

The annotation keyword %method is described in 4.5.6.1 Methods.

The static context for the function body is inherited from the location of the inline function expression.

The variables in scope for the function body include all variables representing the function parameters, as well as all variables that are in scope for the inline function expression.

Note:

Function parameter names can mask variables that would otherwise be in scope for the function body.

The result of an inline function expression is a single function item with the following properties (as defined in Section 7.1 Function Items^DM):

name: Absent.
identity: A new function identity distinct from the identity of any other function item.
Note:
See also 4.5.7 Function Identity.
parameter names: The parameter names in the InlineFunctionExpr’s ParamList.
signature: A FunctionType constructed from the SequenceTypes in the InlineFunctionExpr. An implementation which can determine a more specific signature (for example, through use of type analysis of the function’s body) is permitted to do so.
annotations: If the keyword %method is present, then a list containing a single annotation whose name is a QName with local name "method" and namespace "http://www.w3.org/2012/xquery" and whose value is an empty sequence; otherwise an empty set..
body: The FunctionBody of the InlineFunctionExpr.
captured context: the static context is the static context of the inline function expression. The dynamic context has an absent focus, and a set of variable bindings comprising the variable values component of the dynamic context of the InlineFunctionExpr.

The following are examples of some inline function expressions:

This example creates a function that takes no arguments and returns a sequence of the first 6 primes:
```
function() as xs:integer+ { 2, 3, 5, 7, 11, 13 }
```
This example creates a function that takes two xs:double arguments and returns their product:
```
fn($a as xs:double, $b as xs:double) as xs:double { $a * $b }
```
This example creates and invokes a function that captures the value of a local variable in its scope:
```
let $incrementors := (
  for $x in 1 to 10
  return function($y) as xs:integer { $x + $y }
)
return $incrementors[2](4)
```
The result of this expression is 6

4.5.6.1 Methods

Changes in 4.0 ⬇ ⬆

An inline function may be annotated as a %method, giving it access to its containing map. [Issues 1800 1845 PRs 1817 1853 4 March 2025]

[Definition: A method is a function item that has the annotation %method.]

A method appearing as a value within a map can refer to the containing map as the context value. For example, given the variable:

let $rectangle := { 'height': 3,
                    'width': 4,
                    'area': %method fn() { ?height × ?width }
                  }

The dynamic function call $rectangle?area() returns 12.

The detailed rule is as follows: When the lookup operator ? or ?? is applied to a map M (see 4.13.3 Lookup Expressions), and selects a key/value pair whose value part is a singleton methodF, the function item F′ that is returned by the lookup expression is derived from F as follows:

F′ has a captured context in which the focus is a singleton focus based on the map M.
F′ has no %method annotation and is therefore not a method.
F′ has a separate function identity from F. It is implementation dependent whether repeated evaluations of lookup expressions with the same map and the same key produce functions having the same function identity.
In all other respects F′ has the same properties as F.

Note:

Methods are typically invoked using a dynamic function call such as the call $rectangle?area() in the example above. However, a method selected using a lookup expression such as $rectangle?area can be used in the same way as any other function item. For example, it can be passed as an argument to a higher-order function, or it can be partially applied.

Although methods mimic some of the capability of object-oriented languages, the functionality is more limited:

There is no encapsulation: the entries in a map are all publicly exposed.
There is no class hierarchy, and no inheritance or overriding.
Methods within a map can be removed or replaced in the same way as any other entries in the map.

The context value in the body of a method is bound to the containing map by any lookup expression (using the ? or ?? operators) that selects the method as a singleton item within a key/value pair. It is not bound by other operations that deliver the value, for example a call on map:get or map:for-each. The result of the lookup expression is not itself a method. The means, for example that the expression:

let $rectangle1 := { 'x':3, 'y':4, 'area': %method fn() {?x × ?y} }
let $rectangle2 := { 'x':5, 'y':5, 'area': $rectangle1?area }
return $rectangle2?area()

returns 12, because the function item bound to the key "area" in $rectangle2 is an ordinary function item, not a method.

If the same method is to be used in both variables, this can be written:

let $area := %method fn() {?x × ?y}
let $rectangle1 := { 'x':3, 'y':4, 'area': $area }
let $rectangle2 := { 'x':5, 'y':5, 'area': $area }
return $rectangle2?area()

which returns 25.

An attempt to evaluate a method without binding a context item will typically result in a dynamic error indicating that the context item is not bound. Given the declaration above, the expression $area() raises a type error [err:XPDY0002] because a unary lookup expression (?x or ?y) requires the context value to be bound.

Note:

Methods can be useful when there is a need to write inline recursive functions. For example:

let $lib := {
   'product': %method fn($in as xs:double*) {
                        if (empty( $in ))
                        then 1
                        else head( $in ) × ?product( tail($in) )
                      }
}
return $lib?product( (1.2, 1.3, 1.4) )

In an environment that supports XPath but not XQuery, this mechanism can be used to define all the functions that a particular XPath expression needs to invoke, and these functions can be mutually recursive.

4.13 Maps and Arrays

Most modern programming languages have support for collections of key/value pairs, which may be called maps, dictionaries, associative arrays, hash tables, keyed lists, or objects (these are not the same thing as objects in object-oriented systems). In XPath 4.0, we call these maps. Most modern programming languages also support ordered lists of values, which may be called arrays, vectors, or sequences. In XPath 4.0, we have both sequences and arrays. Unlike sequences, an array is an item, and can appear as an item in a sequence.

Note:

The XPath 4.0 specification focuses on syntax provided for maps and arrays, especially constructors and lookup.

Some of the functionality typically needed for maps and arrays is provided by functions defined in Section 17 Processing maps^FO and Section 18 Processing arrays^FO, including functions used to read JSON to create maps and arrays, serialize maps and arrays to JSON, combine maps to create a new map, remove map entries to create a new map, iterate over the keys of a map, convert an array to create a sequence, combine arrays to form a new array, and iterate over arrays in various ways.

4.13.3 Lookup Expressions

Changes in 4.0 ⬇ ⬆

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.
A deep lookup operator ?? is provided for searching trees of maps and arrays. [Issue 297 PR 837 23 November 2023]
Lookup expressions can now take a modifier (such as keys, values, or pairs) enabling them to return structured results rather than a flattened sequence. [Issues 960 1094 PR 1125 23 April 2024]
An inline function may be annotated as a %method, giving it access to its containing map. [Issues 1800 1845 PRs 1817 1853 4 March 2025]
An inline function may be annotated as a %method, giving it access to its containing map. [Issues 1800 1845 PRs 1817 1853 4 March 2025]

XPath 4.0 provides two lookup operators ? and ?? for maps and arrays. These provide a terse syntax for accessing the entries in a map or the members of an array.

The operator "?", known as the shallow lookup operator, returns values found immediately in the operand map or array. The operator "??", known as the deep lookup operator, also searches nested maps and arrays. The effect of the deep lookup operator "??" is explained in 4.13.3.3 Deep Lookup.

4.14 Conditional Expressions

Changes in 4.0 ⬇ ⬆

Alternative syntax for conditional expressions is available: if (condition) { X } else { Y }, with the else part being optional. [Issue 234 PR 284 23 January 2023]

XPath 4.0 allows conditional expressions to be written in several different ways.

`IfExpr`	::=	`"if" "(" Expr ")" (UnbracedActions \| BracedAction)`
`Expr`	::=	`(ExprSingle ++ ",")`
`ExprSingle`	::=	`ForExpr \| LetExpr \| QuantifiedExpr \| IfExpr \| OrExpr`
`UnbracedActions`	::=	`"then" ExprSingle "else" ExprSingle`
`BracedAction`	::=	`EnclosedExpr`
`EnclosedExpr`	::=	`"{" Expr? "}"`

The braced expression if (C) then {T} is equivalent to the unbraced expression if (C) then T else ().

The value V of a conditional expression in the form if (C) then T else E is obtained as follows:

Let B be the effective boolean value of the test expression C, as defined in 2.5.4 Effective Boolean Value.
If B is true, V is the result of evaluating T.
Otherwise, V is the result of evaluating E.

Conditional expressions have a special rule for propagating dynamic errors: expressions whose value is not needed for computing the result are guarded, as described in 2.4.5 Guarded Expressions, to prevent spurious dynamic errors.

Here are some examples of conditional expressions:

In this example, the test expression is a comparison expression:

if ($widget1/unit-cost < $widget2/unit-cost)
then $widget1
else $widget2

In this example, the test expression tests for the existence of an attribute named discounted, independently of its value:
```
if ($part/@discounted)
then $part/wholesale
else $part/retail
```
The following example returns the attribute node @discount provided the value of @price is greater than 100; otherwise it returns the empty sequence:
```
if (@price gt 100) { @discount }
```

The following example tests a number of conditions:

if (@code = 1) then
  "food"
else if (@code = 2) then
  "fashion"
else if (@code = 3) then
  "household"
else 
  "general"

Note:

The “dangling else ambiguity” found in many other languages cannot arise:

In the unbraced format, both the then and else clauses are mandatory.
In the braced format, the expression terminates unambiguously with the closing brace.

I Change Log (Non-Normative)

Use the arrows to browse significant changes since the 3.1 version of this specification.
See 1 Introduction
Sections with significant changes are marked Δ in the table of contents.
See 1 Introduction
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
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
Record types are added as a new kind of ItemType, constraining the value space of maps.
See 3.2.8.3 Record Types
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
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
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
The symbols × and ÷ can be used for multiplication and division.
See 4.8 Arithmetic Expressions
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
Operators such as < and > can use the full-width forms ＜ and ＞ to avoid the need for XML escaping.
See 4.10.2 General Comparisons
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
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
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
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
Parameter names may be included in a function signature; they are purely documentary.
See 3.2.8.1 Function Types
PR tba
Predicates in filter expressions for maps and arrays can now be numeric.
See 4.13.4 Filter Expressions for Maps and Arrays
The static typing feature has been dropped.
See 5 Conformance
The syntax record() is allowed; the only thing it matches is an empty map.
See 3.2.8.3 Record Types
The context value static type, which was there purely to assist in static typing, has been dropped.
See 2.2.1 Static Context
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
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
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
PR 159
Keyword arguments are allowed on static function calls, as well as positional arguments.
See 4.5.1.1 Static Function Call Syntax
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
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
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
PR 284
Alternative syntax for conditional expressions is available: if (condition) { X } else { Y }, with the else part being optional.
See 4.14 Conditional Expressions
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
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
PR 326
Support for higher-order functions is now a mandatory feature (in 3.1 it was optional).
See 5 Conformance
PR 344
A for member clause is added to FLWOR expressions to allow iteration over an array.
See 4.12.1 For Expressions
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
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
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
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
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
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
PR 691
Enumeration types are added as a new kind of ItemType, constraining the value space of strings.
See 3.2.6 Enumeration Types
PR 728
The syntax record(*) is allowed; it matches any map.
See 3.2.8.3 Record Types
PR 815
The coercion rules now allow conversion in either direction between xs:hexBinary and xs:base64Binary.
See 3.4 Coercion Rules
PR 837
A deep lookup operator ?? is provided for searching trees of maps and arrays.
See 4.13.3 Lookup Expressions
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
PR 996
The value of a predicate in a filter expression can now be a sequence of integers.
See 4.4 Filter Expressions
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
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
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
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
PR 1132
Choice item types (an item type allowing a set of alternative item types) are introduced.
See 3.2.5 Choice Item Types
PR 1163
Filter expressions for maps and arrays are introduced.
See 4.13.4 Filter Expressions for Maps and Arrays
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
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
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
PR 1249
A for key/value clause is added to FLWOR expressions to allow iteration over maps.
See 4.12.1 For Expressions
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
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
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
PR 1361
The term atomic value has been replaced by atomic item.
See 2.1.2 Values
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
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
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
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

XML Path Language (XPath) 4.0 WG Review Draft

W3C Editor's Draft 23 February 2026

Abstract

Status of this Document

Dedication

4 Expressions

4.5 Functions

4.5.6 Inline Function Expressions

4.5.6.1 Methods

4.13 Maps and Arrays

4.13.3 Lookup Expressions

4.14 Conditional Expressions

I Change Log (Non-Normative)