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 2 February12 March 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.20 Arrow Expressions

Changes in 4.0  

  1. An arrow operator may now be followed by any dynamic function call; theThe 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.  [IssueIssues 1716 1829 ]

Arrow expressions apply a function to a value, using the value of the left-hand expression as the first argument to the function.

ArrowExpr::=UnaryExpr (SequenceArrowTargetMappingArrowTargetLookupArrowTarget)*
UnaryExpr::=("-" | "+")* ValueExpr
SequenceArrowTarget::="=>" ArrowTarget
ArrowTarget::=FunctionCall | DynamicFunctionCallRestrictedDynamicCall
FunctionCall::=EQNameArgumentList
/* xgc: reserved-function-names */
/* gn: parens */
DynamicFunctionCallRestrictedDynamicCallDynamicFunctionCallRestrictedDynamicCall::=PostfixExpr(VarRef | ParenthesizedExpr | FunctionItemExpr | MapConstructor | ArrayConstructor) PositionalArgumentList
MappingArrowTargetVarRefMappingArrowTargetVarRef::="=!>$" ArrowTargetEQName
LookupArrowTargetParenthesizedExprLookupArrowTargetParenthesizedExpr::="=?>(" NCNamePositionalArgumentListExpr? ")"
FunctionItemExpr::=NamedFunctionRef | InlineFunctionExpr
NamedFunctionRef::=EQName "#" IntegerLiteral
/* xgc: reserved-function-names */
InlineFunctionExpr::=("function" | "fn") FunctionSignature? FunctionBody
MapConstructor::="map"? "{" (MapConstructorEntry ** ",") "}"
ArrayConstructor::=SquareArrayConstructor | CurlyArrayConstructor
PositionalArgumentList::="(" PositionalArguments? ")"
PositionalArguments::=(Argument ++ ",")
MappingArrowTarget::="=!>" ArrowTarget
LookupArrowTarget::="=?>" NCNamePositionalArgumentList
Argument::=ExprSingle | ArgumentPlaceholder
ExprSingle::=ForExpr
| LetExpr
| QuantifiedExpr
| IfExpr
| OrExpr
ArgumentPlaceholder::="?"

The arrow syntax is particularly helpful when applying multiple functions to a value in turn. For example, the following expression invites syntax errors due to misplaced parentheses:

tokenize((normalize-unicode(upper-case($string))),"\s+")

In the following reformulation, it is easier to see that the parentheses are balanced:

$string => upper-case() => normalize-unicode() => tokenize("\s+")

When the operator is written as =!>, the function is applied to each item in the sequence in turn. Assuming that $string is a single string, the above example could equally be written:

$string =!> upper-case() =!> normalize-unicode() =!> tokenize("\s+")

The difference between the two operators is seen when the left-hand operand evaluates to a sequence:

(1, 2, 3) => avg()

returns a value of only one item, 2, the average of all three items, whereas

(1, 2, 3) =!> avg()

returns the original sequence of three items, (1, 2, 3), each item being the average of itself. The following example:

"The cat sat on the mat"
=> tokenize()
=!> concat(".")
=!> upper-case()
=> string-join(" ")

returns "THE. CAT. SAT. ON. THE. MAT.". The first arrow could be written either as => or =!> because the operand is a singleton; the next two arrows have to be =!> because the function is applied to each item in the tokenized sequence individually; the final arrow must be => because the string-join function applies to the sequence as a whole.

Note:

It may be useful to think of this as a map/reduce pipeline. The functions introduced by =!> are mapping operations; the function introduced by => is a reduce operation.

The following example introduces an inline function to the pipeline:

(1 to 5) =!> xs:double() =!> math:sqrt() =!> fn($a) { $a + 1 }() => sum()

This is equivalent to sum((1 to 5) ! (math:sqrt(xs:double(.)) + 1)).

The same effect can be achieved using a focus function:

(1 to 5) =!> xs:double() =!> math:sqrt() =!> fn { . + 1 }() => sum()

It could also be expressed using the mapping operator !:

(1 to 5) ! xs:double(.) ! math:sqrt(.) ! (. + 1) => sum()

Where the value of an expression is a map containing functions, simulating the behavior of objects in object-oriented languages, then the lookup arrow operator=?> can be used to retrieve a function from the map and to invoke the function with the map as its first argument. For example, if my:rectangle returns a map with entries width, height, expand, and area, then it becomes possible to write:

my:rectangle(3, 5) =?> expand(2) =?> area()

Note:

The ArgumentList of the function call may include PlaceHolders, though this is not especially useful. For example, the expression "$" => concat(?) is equivalent to concat("$", ?): its value is a function that prepends a supplied string with a $ symbol.

Note:

The ArgumentList may include keyword arguments if the function is identified statically (that is, by name). For example, the following is valid: $xml => xml-to-json(indent := true()) => parse-json(escape := false()).

The sequence arrow operator thus applies the supplied function to the left-hand operand as a whole, while the mapping arrow operator applies the function to each item in the value of the left-hand operand individually. In the case where the result of the left-hand operand is a single item, the two operators have the same effect.

Note:

The mapping arrow symbol =!> is intended to suggest a combination of function application (=>) and sequence mapping (!) combined in a single operation.

Similarly, the lookup arrow symbol =?> is intended to suggest a combination of function application (=>) and map lookup (?) in a single operation.

Note:

The expression U => $V(X)(Y) satisfies the grammar, but its meaning might not be obvious. It is interpreted as being equivalent to $V(X)(U, Y). The same applies to the mapping arrow operator: U =!> $V(X)(Y) is interpreted as for $u in U return $V(X)($u, Y). This follows from the way that the syntax of a DynamicFunctionCall is defined.

The construct on the right-hand side of the arrow operator (=>) can either be a static function call, or a restricted form of dynamic function call. The restrictions are there to ensure that the two forms can be distinguished by the parser with limited lookahead. For a dynamic call, the function item to be called can be expressed as a variable reference, an inline function expression, a named function reference, a map constructor, or an array constructor. Any other expression used to return the required function item must be enclosed in parentheses.

4.20.1 Sequence Arrow Expressions

[Definition: The sequence arrow operator=> applies a function to a supplied sequence.] It is defined as follows:

Note:

Although the syntax of an arrow expression makes use of the grammatical productions FunctionCall and DynamicFunctionCall, these are not evaluated in the same way as a function call that appears as a free-standing expression.

4.20.2 Mapping Arrow Expressions

Changes in 4.0  

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

[Definition: The mapping arrow operator=!> applies a function to each item in a sequence.] It is defined as follows:

A XPath 4.0 Grammar

A.1 EBNF

Changes in 4.0  

  1. 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.  [Issue 1366 PR 1498]

The grammar of XPath 4.0 uses the same simple Extended Backus-Naur Form (EBNF) notation as [XML 1.0] with the following differences.

  • The notation XYZ ** "," indicates a sequence of zero or more occurrences of XYZ, with a single comma between adjacent occurrences.

  • The notation XYZ ++ "," indicates a sequence of one or more occurrences of XYZ, with a single comma between adjacent occurrences.

  • All named symbols have a name that begins with an uppercase letter.

  • It adds a notation for referring to productions in external specifications.

  • Comments or extra-grammatical constraints on grammar productions are between '/*' and '*/' symbols.

    • A 'xgc:' prefix is an extra-grammatical constraint, the details of which are explained in A.1.2 Extra-grammatical Constraints

    • A 'ws:' prefix explains the whitespace rules for the production, the details of which are explained in A.3.5 Whitespace Rules

    • A 'gn:' prefix means a 'Grammar Note', and is meant as a clarification for parsing rules, and is explained in A.1.3 Grammar Notes. These notes are not normative.

The terminal symbols for this grammar include the quoted strings used in the production rules below, and the terminal symbols defined in section A.3.1 Terminal Symbols. The grammar is a little unusual in that parsing and tokenization are somewhat intertwined: for more details see A.3 Lexical structure.

The EBNF notation is described in more detail in A.1.1 Notation.

AbbrevForwardStep::=("@" NodeTest) | SimpleNodeTest
AbbrevReverseStep::=".."
AdditiveExpr::=MultiplicativeExpr (("+" | "-") MultiplicativeExpr)*
AndExpr::=ComparisonExpr ("and" ComparisonExpr)*
AnyArrayType::="array" "(" "*" ")"
AnyFunctionType::=("function" | "fn") "(" "*" ")"
AnyItemTest::="item" "(" ")"
AnyKindTest::="node" "(" ")"
AnyMapType::="map" "(" "*" ")"
AnyRecordType::="record" "(" "*" ")"
Argument::=ExprSingle | ArgumentPlaceholder
ArgumentList::="(" ((PositionalArguments ("," KeywordArguments)?) | KeywordArguments)? ")"
ArgumentPlaceholder::="?"
ArrayConstructor::=SquareArrayConstructor | CurlyArrayConstructor
ArrayType::=AnyArrayType | TypedArrayType
ArrowExpr::=UnaryExpr (SequenceArrowTargetMappingArrowTargetLookupArrowTarget)*
ArrowTarget::=FunctionCall | DynamicFunctionCallRestrictedDynamicCall
AttributeName::=EQName
AttributeTest::="attribute" "(" (NameTestUnion ("," TypeName)?)? ")"
AxisStep::=(ReverseStep | ForwardStep) Predicate*
BracedAction::=EnclosedExpr
CastableExpr::=CastExpr ("castable" "as" CastTarget "?"?)?
CastExpr::=PipelineExpr ("cast" "as" CastTarget "?"?)?
CastTarget::=TypeName | ChoiceItemType | EnumerationType
ChoiceItemType::="(" (ItemType ++ "|") ")"
CommentTest::="comment" "(" ")"
ComparisonExpr::=OtherwiseExpr ((ValueComp | GeneralComp | NodeComp) OtherwiseExpr)?
ContextValueRef::="."
CurlyArrayConstructor::="array" EnclosedExpr
DocumentTest::="document-node" "(" (ElementTest | SchemaElementTest | NameTestUnion)? ")"
DynamicFunctionCall::=PostfixExprPositionalArgumentList
ElementName::=EQName
ElementTest::="element" "(" (NameTestUnion ("," TypeName "?"?)?)? ")"
EnclosedExpr::="{" Expr? "}"
EnumerationType::="enum" "(" (StringLiteral ++ ",") ")"
EQName::=QName | URIQualifiedName
Expr::=(ExprSingle ++ ",")
ExprSingle::=ForExpr
| LetExpr
| QuantifiedExpr
| IfExpr
| OrExpr
ExtensibleFlag::="," "*"
FieldDeclaration::=FieldName "?"? ("as" SequenceType)?
FieldName::=NCName | StringLiteral
FilterExpr::=PostfixExprPredicate
FilterExprAM::=PostfixExpr "?[" Expr "]"
ForBinding::=ForItemBinding | ForMemberBinding | ForEntryBinding
ForClause::="for" (ForBinding ++ ",")
ForEntryBinding::=((ForEntryKeyBindingForEntryValueBinding?) | ForEntryValueBinding) PositionalVar? "in" ExprSingle
ForEntryKeyBinding::="key" VarNameAndType
ForEntryValueBinding::="value" VarNameAndType
ForExpr::=ForClauseForLetReturn
ForItemBinding::=VarNameAndTypePositionalVar? "in" ExprSingle
ForLetReturn::=ForExpr | LetExpr | ("return" ExprSingle)
ForMemberBinding::="member" VarNameAndTypePositionalVar? "in" ExprSingle
ForwardAxis::=("attribute"
| "child"
| "descendant"
| "descendant-or-self"
| "following"
| "following-or-self"
| "following-sibling"
| "following-sibling-or-self"
| "namespace"
| "self") "::"
ForwardStep::=(ForwardAxisNodeTest) | AbbrevForwardStep
FunctionBody::=EnclosedExpr
FunctionCall::=EQNameArgumentList
/* xgc: reserved-function-names */
/* gn: parens */
FunctionItemExpr::=NamedFunctionRef | InlineFunctionExpr
FunctionSignature::="(" ParamList ")" TypeDeclaration?
FunctionType::=AnyFunctionType
| TypedFunctionType
GeneralComp::="=" | "!=" | "<" | "<=" | ">" | ">="
IfExpr::="if" "(" Expr ")" (UnbracedActions | BracedAction)
InlineFunctionExpr::=("function" | "fn") FunctionSignature? FunctionBody
InstanceofExpr::=TreatExpr ("instance" "of" SequenceType)?
IntersectExceptExpr::=InstanceofExpr (("intersect" | "except") InstanceofExpr)*
ItemType::=AnyItemTest | TypeName | KindTest | FunctionType | MapType | ArrayType | RecordType | EnumerationType | ChoiceItemType
KeySpecifier::=NCName | IntegerLiteral | StringLiteral | VarRef | ParenthesizedExpr | LookupWildcard
KeywordArgument::=EQName ":=" Argument
KeywordArguments::=(KeywordArgument ++ ",")
KindTest::=DocumentTest
| ElementTest
| AttributeTest
| SchemaElementTest
| SchemaAttributeTest
| PITest
| CommentTest
| TextTest
| NamespaceNodeTest
| AnyKindTest
LetBinding::=VarNameAndType ":=" ExprSingle
LetClause::="let" (LetBinding ++ ",")
LetExpr::=LetClauseForLetReturn
Literal::=NumericLiteral | StringLiteral
Lookup::=("?" | "??") (Modifier "::")? KeySpecifier
LookupArrowTarget::="=?>" NCNamePositionalArgumentList
LookupExpr::=PostfixExprLookup
LookupWildcard::="*"
MapConstructor::="map"? "{" (MapConstructorEntry ** ",") "}"
MapConstructorEntry::=MapKeyExpr ":" MapValueExpr
MapKeyExpr::=ExprSingle
MappingArrowTarget::="=!>" ArrowTarget
MapType::=AnyMapType | TypedMapType
MapValueExpr::=ExprSingle
Modifier::="pairs" | "keys" | "values" | "items"
MultiplicativeExpr::=UnionExpr (("*" | "×" | "div" | "÷" | "idiv" | "mod") UnionExpr)*
NamedFunctionRef::=EQName "#" IntegerLiteral
/* xgc: reserved-function-names */
NamespaceNodeTest::="namespace-node" "(" ")"
NameTest::=EQName | Wildcard
NameTestUnion::=(NameTest ++ "|")
NodeComp::="is" | "<<" | ">>"
NodeTest::=UnionNodeTest | SimpleNodeTest
NumericLiteral::=IntegerLiteral | HexIntegerLiteral | BinaryIntegerLiteral | DecimalLiteral | DoubleLiteral
OccurrenceIndicator::="?" | "*" | "+"
/* xgc: occurrence-indicators */
OrExpr::=AndExpr ("or" AndExpr)*
OtherwiseExpr::=StringConcatExpr ("otherwise" StringConcatExpr)*
ParamList::=(VarNameAndType ** ",")
ParenthesizedExpr::="(" Expr? ")"
PathExpr::=("/" RelativePathExpr?)
| ("//" RelativePathExpr)
| RelativePathExpr
/* xgc: leading-lone-slash */
PipelineExpr::=ArrowExpr ("->" ArrowExpr)*
PITest::="processing-instruction" "(" (NCName | StringLiteral)? ")"
PositionalArgumentList::="(" PositionalArguments? ")"
PositionalArguments::=(Argument ++ ",")
PositionalVar::="at" VarName
PostfixExpr::=PrimaryExpr | FilterExpr | DynamicFunctionCall | LookupExpr | FilterExprAM
Predicate::="[" Expr "]"
PrimaryExpr::=Literal
| VarRef
| ParenthesizedExpr
| ContextValueRef
| FunctionCall
| FunctionItemExpr
| MapConstructor
| ArrayConstructor
| StringTemplate
| UnaryLookup
QuantifiedExpr::=("some" | "every") (QuantifierBinding ++ ",") "satisfies" ExprSingle
QuantifierBinding::=VarNameAndType "in" ExprSingle
RangeExpr::=AdditiveExpr ("to" AdditiveExpr)?
RecordType::=AnyRecordType | TypedRecordType
RelativePathExpr::=StepExpr (("/" | "//") StepExpr)*
RestrictedDynamicCall::=(VarRef | ParenthesizedExpr | FunctionItemExpr | MapConstructor | ArrayConstructor) PositionalArgumentList
ReverseAxis::=("ancestor"
| "ancestor-or-self"
| "parent"
| "preceding"
| "preceding-or-self"
| "preceding-sibling"
| "preceding-sibling-or-self") "::"
ReverseStep::=(ReverseAxisNodeTest) | AbbrevReverseStep
SchemaAttributeTest::="schema-attribute" "(" AttributeName ")"
SchemaElementTest::="schema-element" "(" ElementName ")"
SequenceArrowTarget::="=>" ArrowTarget
SequenceType::=("empty-sequence" "(" ")")
| (ItemTypeOccurrenceIndicator?)
SimpleMapExpr::=PathExpr ("!" PathExpr)*
SimpleNodeTest::=KindTest | NameTest
SquareArrayConstructor::="[" (ExprSingle ** ",") "]"
StepExpr::=PostfixExpr | AxisStep
StringConcatExpr::=RangeExpr ("||" RangeExpr)*
StringTemplate::="`" (StringTemplateFixedPart | StringTemplateVariablePart)* "`"
/* ws: explicit */
StringTemplateFixedPart::=((Char - ('{' | '}' | '`')) | "{{" | "}}" | "``")*
/* ws: explicit */
StringTemplateVariablePart::=EnclosedExpr
/* ws: explicit */
TextTest::="text" "(" ")"
TreatExpr::=CastableExpr ("treat" "as" SequenceType)?
TypedArrayType::="array" "(" SequenceType ")"
TypeDeclaration::="as" SequenceType
TypedFunctionParam::=("$" EQName "as")? SequenceType
TypedFunctionType::=("function" | "fn") "(" (TypedFunctionParam ** ",") ")" "as" SequenceType
TypedMapType::="map" "(" ItemType "," SequenceType ")"
TypedRecordType::="record" "(" (FieldDeclaration ** ",") ExtensibleFlag? ")"
TypeName::=EQName
UnaryExpr::=("-" | "+")* ValueExpr
UnaryLookup::=("?" | "??") (Modifier "::")? KeySpecifier
UnbracedActions::="then" ExprSingle "else" ExprSingle
UnionExpr::=IntersectExceptExpr (("union" | "|") IntersectExceptExpr)*
UnionNodeTest::="(" SimpleNodeTest ("|" SimpleNodeTest)* ")"
ValueComp::="eq" | "ne" | "lt" | "le" | "gt" | "ge"
ValueExpr::=SimpleMapExpr
VarName::="$" EQName
VarNameAndType::="$" EQNameTypeDeclaration?
VarRef::="$" EQName
Wildcard::="*"
| (NCName ":*")
| ("*:" NCName)
| (BracedURILiteral "*")
/* ws: explicit */
XPath::=Expr

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. The symbols × and ÷ can be used for multiplication and division.

    See 4.8 Arithmetic Expressions

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

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

    See 4.10.2 General Comparisons

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

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

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

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

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

    See 3.2.8.1 Function Types

  15. PR tba 

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

    See 4.13.4 Filter Expressions for Maps and Arrays

  16. The static typing feature has been dropped.

    See 5 Conformance

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

    See 3.2.8.3 Record Types

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

    See 2.2.1 Static Context

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

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

  21. An arrow operator may now be followed by any dynamic function call; the dynamic function call no longer needs to start with a variable reference or a parenthesized expression.

    See 4.20 Arrow Expressions

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

  23. PR 159 

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

    See 4.5.1.1 Static Function Call Syntax

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

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

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

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

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

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

  30. PR 326 

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

    See 5 Conformance

  31. PR 344 

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

    See 4.12.1 For Expressions

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

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

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

  35. 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.2.5 Inline Function Expressions

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

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

  38. PR 691 

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

    See 3.2.6 Enumeration Types

  39. PR 728 

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

    See 3.2.8.3 Record Types

  40. PR 815 

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

    See 3.4 Coercion Rules

  41. PR 837 

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

    See 4.13.3 Lookup Expressions

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

  43. PR 985 

    With the lookup arrow expression and the =?> operator, a function in a map can be looked up and called with the map as first argument.

    See 4.20.3 Lookup Arrow Expressions

  44. PR 996 

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

    See 4.4 Filter Expressions

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

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

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

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

  49. PR 1132 

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

    See 3.2.5 Choice Item Types

  50. PR 1163 

    Filter expressions for maps and arrays are introduced.

    See 4.13.4 Filter Expressions for Maps and Arrays

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

  52. 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.2.5 Inline Function Expressions

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

  54. PR 1249 

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

    See 4.12.1 For Expressions

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

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

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

  58. PR 1361 

    The term atomic value has been replaced by atomic item.

    See 2.1.2 Values

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

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

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

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