XML Path Language (XPath) 4.0 WG Review Draft

2.1.3 Values

[Definition: In the data model, a value is always a sequence.]

[Definition: A sequence is an ordered collection of zero or more items.]

[Definition: An item is either an atomic item, a node, or a function item.]

[Definition: An atomic item is a value in the value space of an atomic type, as defined in [XML Schema 1.0] or [XML Schema 1.1].]

[Definition: An XNode is an instance of one of the node kinds defined in [XDM 4.0] section 7.1 XML Nodes.] Each XNode has a unique node identity, a typed value, and a string value. In addition, some XNodes have a name. The typed value of an XNode is a sequence of zero or more atomic items. The string value of an XNode is a value of type xs:string. The name of an XNode is a value of type xs:QName.

[Definition: Except where the context indicates otherwise, the term node is used as a synonym for XNode.]

[Definition: A JNode (see also [XDM 4.0] section 8.4 JNodes) is an encapsulation of a value as it appears within a tree of maps and arrays, typically (but not necessarily) obtained by parsing JSON texts.]

[Definition: A GNode (for generalized node) is either an XNode or a JNode.]

[Definition: A function item is an item that can be called using a dynamic function call.]

Maps (see 4.14.1 Maps) and arrays (see 4.14.2 Arrays) are specific kinds of function items.

[Definition: A sequence containing exactly one item is called a singleton.] An item is identical to a singleton sequence containing that item. Sequences are never nested—for example, combining the values 1, (2, 3), and ( ) into a single sequence results in the sequence (1, 2, 3). [Definition: A sequence containing zero items is called an empty sequence.] [Definition: A sequence containing exactly one item is called a singleton.] An item is identical to a singleton sequence containing that item. Sequences are never nested—for example, combining the values 1, (2, 3), and ( ) into a single sequence results in the sequence (1, 2, 3). [Definition: The sequence containing zero items is called the empty sequence.] [Definition: A sequence containing exactly one item is called a singleton.] An item is identical to a singleton sequence containing that item. Sequences are never nested—for example, combining the values 1, (2, 3), and ( ) into a single sequence results in the sequence (1, 2, 3). [Definition: AThe sequence containing zero items is called anthe empty sequence.]

[Definition: The term XDM instance is used, synonymously with the term value, to denote an unconstrained sequence of items.]

2.4.3 Expression Processing

XPath 4.0 defines two phases of processing called the static analysis phase and the dynamic evaluation phase (see Figure 1). During the static analysis phase, static errors, dynamic errors, or type errors may be raised. During the dynamic evaluation phase, only dynamic errors or type errors may be raised. These kinds of errors are defined in 2.5.1 Kinds of Errors.

Within each phase, an implementation is free to use any strategy or algorithm whose result conforms to the specifications in this document.

2.5.4 Errors and Optimization

Because different implementations may choose to evaluate or optimize an expression in different ways, certain aspects of raising dynamic errors are implementation-dependent, as described in this section.

An implementation is always free to evaluate the operands of an operator in any order.

In some cases, a processor can determine the result of an expression without accessing all the data that would be implied by the formal expression semantics. For example, the formal description of filter expressions suggests that $s[1] should be evaluated by examining all the items in sequence $s, and selecting all those that satisfy the predicate position()=1. In practice, many implementations will recognize that they can evaluate this expression by taking the first item in the sequence and then exiting. If $s is defined by an expression such as //book[author eq 'Berners-Lee'], then this strategy may avoid a complete scan of a large document and may therefore greatly improve performance. However, a consequence of this strategy is that a dynamic error or type error that would be detected if the expression semantics were followed literally might not be detected at all if the evaluation exits early. In this example, such an error might occur if there is a book element in the input data with more than one author subelement.

The extent to which a processor may optimize its access to data, at the cost of not raising errors, is defined by the following rules.

Consider an expression Q that has an operand (sub-expression) E. In general the value of E is a sequence. At an intermediate stage during evaluation of the sequence, some of its items will be known and others will be unknown. If, at such an intermediate stage of evaluation, a processor is able to establish that there are only two possible outcomes of evaluating Q, namely the value V or an error, then the processor may deliver the result V without evaluating further items in the operand E. For this purpose, two values are considered to represent the same outcome if their items are pairwise the same, where nodes are the same if they have the same identity, and values are the same if they are equal and have exactly the same type.

There is an exception to this rule: If a processor evaluates an operand E (wholly or in part), then it is required to establish that the actual value of the operand E does not violate any constraints on its cardinality. For example, the expression $e eq 0 results in a type error if the value of $e contains two or more items. A processor is not allowed to decide, after evaluating the first item in the value of $e and finding it equal to zero, that the only possible outcomes are the value true or a type error caused by the cardinality violation. It must establish that the value of $e contains no more than one item.

These rules apply to all the operands of an expression considered in combination: thus if an expression has two operands E1 and E2, it may be evaluated using any samples of the respective sequences that satisfy the above rules.

The rules cascade: if A is an operand of B and B is an operand of C, then the processor needs to evaluate only a sufficient sample of B to determine the value of C, and needs to evaluate only a sufficient sample of A to determine this sample of B.

The effect of these rules is that the processor is free to stop examining further items in a sequence as soon as it can establish that further items would not affect the result except possibly by causing an error. For example, the processor may return true as the result of the expression S1 = S2 as soon as it finds a pair of equal values from the two sequences.

Another consequence of these rules is that where none of the items in a sequence contributes to the result of an expression, the processor is not obliged to evaluate any part of the sequence. Again, however, the processor cannot dispense with a required cardinality check: if anthe empty sequence is not permitted in the relevant context, then the processor must ensure that the operand is not anthe empty sequence.

Examples:

• If an implementation can find (for example, by using an index) that at least one item returned by $expr1 in the following example has the value 47, it is allowed to return true as the result of the some expression, without searching for another item returned by $expr1 that would raise an error if it were evaluated.

  some $x in $expr1 satisfies $x = 47

• In the following example, if an implementation can find (for example, by using an index) the product element-nodes that have an id child with the value 47, it is allowed to return these nodes as the result of the path expression, without searching for another product node that would raise an error because it has an id child whose value is not an integer.

  //product[id = 47]

For a variety of reasons, including optimization, implementations may rewrite expressions into a different form. There are a number of rules that limit the extent of this freedom:

• Other than the raising or not raising of errors, the result of evaluating a rewritten expression must conform to the semantics defined in this specification for the original expression.

  Note:

  This allows an implementation to return a result in cases where the original expression would have raised an error, or to raise an error in cases where the original expression would have returned a result. The main cases where this is likely to arise in practice are (a) where a rewrite changes the order of evaluation, such that a subexpression causing an error is evaluated when the expression is written one way and is not evaluated when the expression is written a different way, and (b) where intermediate results of the evaluation cause overflow or other out-of-range conditions.

  Note:

  This rule does not mean that the result of the expression will always be the same in non-error cases as if it had not been rewritten, because there are many cases where the result of an expression is to some degree implementation-dependent or implementation-defined.

• The rules described in 2.5.5 Guarded Expressions ensure that for certain kinds of expression (for example conditional expressions), changing the order of evaluation of subexpressions does not result in dynamic errors that would not otherwise occur.

• Expressions must not be rewritten in such a way as to create or remove static errors. The static errors in this specification are defined for the original expression, and must be preserved if the expression is rewritten.

• As stated earlier, an expression must not be rewritten to dispense with a required cardinality check: for example, string-length(//title) must raise an error if the document contains more than one title element.

2.5.5 Guarded Expressions

[Definition: An expression E is said to be guarded by some governing condition C if evaluation of E is not allowed to fail with a dynamic error except when C applies.]

For example, in a conditional expression if (P) then T else F, the subexpression T is guarded by P, and the subexpression F is guarded by not(P). One way an implementation can satisfy this rule is by not evaluating T unless P is true, and likewise not evaluating F unless P is false. Another way of satisfying the rule is for the implementation to evaluate all the subexpressions, but to catch any errors that occur in a guarded subexpression so they are not propagated.

The existence of this rule enables errors to be prevented by writing expressions such as if ($y eq 0) then "N/A" else ($x div $y). This example will never fail with a divide-by-zero error because the else branch of the conditional is guarded.

Similarly, in the mapping expression E1!E2, the subexpression E₂ is guarded by the existence of an item from E₁. This means, for example, that the expression (1 to $n)!doc('bad.xml') must not raise a dynamic error if $n is zero. The rule governing evaluation of guarded expressions is phrased so as not to disallow “loop-lifting” or “constant-folding” optimizations whose aim is to avoid repeated evaluation of a common subexpression; but such optimizations must not result in errors that would not otherwise occur.

The complete list of expressions that have guarded subexpressions is as follows:

• In a conditional expression (IfExpr) the then branch is guarded by the condition being true, and the else branch is guarded by the condition being false.

• In an and expression, the second operand is guarded by the value of the first operand being true.

• In an or expression, the second operand is guarded by the value of the first operand being false.

• In an otherwise expression (OtherwiseExpr), the second operand is guarded by the value of the first operand being an empty sequence.In an otherwise expression (OtherwiseExpr), the second operand is guarded by the value of the first operand being the empty sequence.In an otherwise expression (OtherwiseExpr), the second operand is guarded by the value of the first operand being anthe empty sequence.

• In a path expression of the form E1/E2 or E1//E2, and in a mapping expression of the form E1!E2, the right-hand operand E₂ is guarded by the existence of at least one item in the result of evaluating E₁.

  This rule applies even if E₂ does not reference the context value. For example, no dynamic error can be thrown by the expression (1 to $n)!doc('bad.xml') in the case where $n is zero.

• In a filter expression of the form E[P], the predicate P is guarded by the existence of at least one item in the result of evaluating E.

  This rule has the consequence that in a filter expression with multiple predicates, such as E[P1][P2], evaluation of P₂ must not raise a dynamic error unless P₁ returns true. This rule does not prevent reordering of predicates (for example, to take advantage of indexes), but it does require that any such reordering must not result in errors that would not otherwise occur.

• In a for expression (ForExpr) such as for $x in S return E, the expression E is guarded by the existence of an item bound to $x.

  This means that the expression for $x in 1 to $n return doc('bad.xml') must not raise a dynamic error in the case where $n is zero.

• In a quantified expression (QuantifiedExpr) such as some $x in S satisfies P, the expression P is guarded by the existence of an item bound to $x.

The fact that an expression is guarded does not remove the obligation to report static errors in the expression; nor does it remove the option to report statically detectable type errors.

2.5.6 Implausible Expressions

[Definition: Certain expressions, while not erroneous, are classified as being implausible, because they achieve no useful effect.]

An example of an implausible expression is @code/text(). This expression will always evaluate to an empty sequence, because attribute nodes cannot have text node children. The semantics of the expression are well defined, but it is likely that the user writing this expression intended something different: if they wanted to write an expression that evaluated to an empty sequence, there would be easier ways to write it.An example of an implausible expression is @code/text(). This expression will always evaluate to the empty sequence, because attribute nodes cannot have text node children. The semantics of the expression are well defined, but it is likely that the user writing this expression intended something different: if they wanted to write an expression that evaluated to the empty sequence, there would be easier ways to write it.An example of an implausible expression is @code/text(). This expression will always evaluate to anthe empty sequence, because attribute nodes cannot have text node children. The semantics of the expression are well defined, but it is likely that the user writing this expression intended something different: if they wanted to write an expression that evaluated to anthe empty sequence, there would be easier ways to write it.

Where an expression is classified (by rules in this specification) as being implausible, a processor may (but is not required to) raise a static error.

For reasons of backwards compatibility and interoperability, and to facilitate automatic generation of XPath 4.0 code, a processor must provide a mode of operation in which implausible expressions are not treated as static errors, but are evaluated with the defined semantics for the expression.

Some other examples of implausible expressions include:

• round(tokenize($input)). The result of fn:tokenize is a sequence of strings (xs:string*), while the required type for the first argument of fn:round is optional numeric (xs:numeric?). The expression can succeed only in the exceptional case where the result of fn:tokenize is an empty sequence, in which case the result of fn:round will also be an empty sequence; it is therefore highly likely that the expression was written in error.round(tokenize($input)). The result of fn:tokenize is a sequence of strings (xs:string*), while the required type for the first argument of fn:round is optional numeric (xs:numeric?). The expression can succeed only in the exceptional case where the result of fn:tokenize is the empty sequence, in which case the result of fn:round will also be the empty sequence; it is therefore highly likely that the expression was written in error.round(tokenize($input)). The result of fn:tokenize is a sequence of strings (xs:string*), while the required type for the first argument of fn:round is optional numeric (xs:numeric?). The expression can succeed only in the exceptional case where the result of fn:tokenize is anthe empty sequence, in which case the result of fn:round will also be anthe empty sequence; it is therefore highly likely that the expression was written in error.

• parse-csv($input)?column-names. The signature of the parse-csv function declares its return type as record(columns, rows). There is no field in this record named column-names, and therefore the lookup expression will always return an empty sequence. Again, there is no good reason that a user would write this, so it is likely that it was written in error.parse-csv($input)?column-names. The signature of the parse-csv function declares its return type as record(columns, rows). There is no field in this record named column-names, and therefore the lookup expression will always return the empty sequence. Again, there is no good reason that a user would write this, so it is likely that it was written in error.parse-csv($input)?column-names. The signature of the parse-csv function declares its return type as record(columns, rows). There is no field in this record named column-names, and therefore the lookup expression will always return anthe empty sequence. Again, there is no good reason that a user would write this, so it is likely that it was written in error.

2.6.1 Document Order

An ordering called document order is defined among all the nodes accessible during processing of a given expression, which may consist of one or more trees (documents or fragments).

Document order applies both to XNodes (typically corresponding to nodes in an XML document, and generally referred to simply as nodes), and also to JNodes^DM, often corresponding to the contents of a JSON source text. These are known collectively as GNodes (for "generalized node").Document order applies both to XNodes (typically corresponding to nodes in an XML document, and generally referred to simply as nodes), and also to JNodes, often corresponding to the contents of a JSON source text. These are known collectively as GNodes (for "generalized node").Document order applies both to XNodes (typically corresponding to nodes in an XML document, and generally referred to simply as nodes), and also to JNodesDM, often corresponding to the contents of a JSON source text. These are known collectively as GNodes (for "generalized node").

Document order is defined in [XDM 4.0] section 6.2 Document Order, and its definition is repeated here for convenience. Document order is a total ordering, although the relative order of some nodes is implementation-dependent. [Definition: Informally, document order is the order in which nodes appear in the XML serialization of a document.] [Definition: Document order is stable, which means that the relative order of two nodes will not change during the processing of a given expression, even if this order is implementation-dependent.] [Definition: The node ordering that is the reverse of document order is called reverse document order.]

Within an XTree^DM, (that is, a tree consisting of XNodes), document order satisfies the following constraints:

1. The root node precedes all other nodes.

2. A parent node precedes its children (and therefore its descendants).

3. The children of a node N precede the following siblings of N.

4. Namespace nodes immediately follow the element node with which they are associated. The relative order of namespace nodes is stable but implementation-dependent.

5. Attribute nodes immediately follow the namespace nodes of the element node with which they are associated. The relative order of attribute nodes is stable but implementation-dependent.

6. The relative order of siblings is the order in which they occur in the children property of their parent node.

Similarly, within an JTree^DM, (that is, a tree consisting of JNodes), document order satisfies the following constraints:

1. The root JNode precedes all other JNodes.

2. A parent JNode precedes its children (and therefore its descendants).

3. The children of a JNode N precede the following siblings of N.

4. The children of a JNode that wraps an array follow the ordering of the members of the array.

5. The children of a JNode that wraps a map follow the ordering of the entries in the map.

The relative order of nodes in distinct trees is stable but implementation-dependent, subject to the following constraint: If any node in a given tree T1 is before any node in a different tree T2, then all nodes in tree T1 are before all nodes in tree T2.

2.6.4 Effective Boolean Value

Under certain circumstances (some of which are listed below), it is necessary to find the effective boolean value of a value. [Definition: The effective boolean value of a value is defined as the result of applying the fn:boolean function to the value.]

The dynamic semantics of fn:boolean are repeated here for convenience:

1. If its operand is an empty sequence, fn:boolean returns false.If its operand is the empty sequence, fn:boolean returns false.If its operand is anthe empty sequence, fn:boolean returns false.

2. If its operand is a sequence whose first item is a GNode, fn:boolean returns true.

3. If its operand is a singleton value of type xs:boolean or derived from xs:boolean, fn:boolean returns the value of its operand unchanged.

4. If its operand is a singleton value of type xs:string, xs:anyURI, xs:untypedAtomic, or a type derived from one of these, fn:boolean returns false if the operand value has zero length; otherwise it returns true.

5. If its operand is a singleton value of any numeric type or derived from a numeric type, fn:boolean returns false if the operand value is NaN or is numerically equal to zero; otherwise it returns true.

6. In all other cases, fn:boolean raises a type error [err:FORG0006]^FO40.

   Note:

   For instance, fn:boolean raises a type error if the operand is a function, a map, or an array.

The effective boolean value of a sequence is computed implicitly during processing of the following types of expressions:

• Logical expressions (and, or)

• The fn:not function

• Certain types of predicates, such as a[b]

• Conditional expressions (if)

• Quantified expressions (some, every)

• General comparisons, in XPath 1.0 compatibility mode.

3.1.2 Sequence Type Matching

[Definition: SequenceType matching compares a value with an expected sequence type. ] For example, an instance of expression returns true if a given value matches a given sequence type, and false if it does not.

An XPath 4.0 implementation must be able to determine relationships among the types in type annotations in an XDM instance and the types in the in-scope schema definitions (ISSD).

[Definition: The use of a value that has a dynamic type that is a subtype of the expected type is known as subtype substitution.] Subtype substitution does not change the actual type of a value. For example, if an xs:integer value is used where an xs:decimal value is expected, the value retains its type as xs:integer.

The rules for SequenceType matching are given below, with examples (the examples are for purposes of illustration, and do not cover all possible cases).

• The sequence typeempty-sequence() matches a value that is the empty sequence.

• An ItemType with no OccurrenceIndicator matches any value that contains exactly one item if the ItemType matches that item (see 3.2 Item Types).

• An ItemType with an OccurrenceIndicator matches a value if the number of items in the value matches the OccurrenceIndicator and the ItemType matches each of the items in the value.

An OccurrenceIndicator specifies the number of items in a sequence, as follows:

• ? matches zero or one items

• * matches zero or more items

• + matches one or more items

As a consequence of these rules, any sequence type whose OccurrenceIndicator is * or ? matches a value that is an empty sequence.As a consequence of these rules, any sequence type whose OccurrenceIndicator is * or ? matches a value that is the empty sequence.As a consequence of these rules, any sequence type whose OccurrenceIndicator is * or ? matches a value that is anthe empty sequence.

3.2.8 Function, Map, and Array Types

The following sections describe the syntax for item types for functions, including arrays and maps.

The subtype relation among these types is described in the various subsections of 3.3.2 Subtypes of Item Types.

3.3.2 Subtypes of Item Types

We use the notation A ⊆ B, or itemtype-subtype(A, B) to indicate that an item typeA is a subtype of an item type B. This section defines the rules for deciding whether any two item types have this relationship.

The rules in this section apply to item types, not to item type designators. For example, if the name STR has been defined in the static context as a named item type referring to the type xs:string, then anything said here about the type xs:string applies equally whether it is designated as xs:string or as STR, or indeed as the parenthesized forms (xs:string) or (STR).

References to named item types are handled as described in 3.3.2.10 Subtyping of Named Item Types.

The relationship A ⊆ B is true if and only if at least one of the conditions listed in the following subsections applies:

3.4.2 Item Coercion Rules

The rules in this section are used to process each item J in a supplied sequence, given a required item typeR.

1. If R is a generalized atomic type (for example, if it is an atomic type, a pure union type, or an enumeration type), and J is not an atomic item, then:

   1. J is atomized to produce a sequence of atomic items JJ.

   2. Each atomic item in JJ is coerced to the required type R by recursive application of the item coercion rules (the rules in this section) to produce a value V.

   3. The result is the sequence concatenation of the V values.

   Note:

   For example, if J is an element with type annotation xs:integer, and R is the union type xs:numeric, then the effect is to atomize the element to an xs:integer, and then to coerce the resulting xs:integer to xs:numeric (which leaves the integer unchanged). This is not the same as attempting to coerce the element to each of the alternatives of the union type in turn, which would deliver an instance of xs:double.

2. Otherwise, if R is a choice item type or a pure union type (which includes the case where it is an enumeration type), then:

   1. If J matches (is an instance of) one of the alternatives in R, then J is coerced to the first alternative in R that J matches.

      Note:

      There are two situations where coercing an item to a type that it already matches does not simply return the item unchanged:

      • When the required type is a typed function type (see 3.2.8.1 Function Types), then function coercion is applied to coerce J to that function type, as described in 3.4.4 Function Coercion.

      • When the required type is a record type and the supplied value is a map, then coercion may change the entry order^DM of the entries in the map.

   2. Otherwise, the item coercion rules (the rules in this section) are applied to J recursively with R set to each of the alternatives in the choice or union item type, in order, until an alternative is found that does not result in a type error; a type error is raised only if all alternatives fail.

      The error code used in the event of failure should be the error code arising from the first unsuccessful matching attempt. (The diagnostic information associated with the error may also describe how further attempts failed.)

   Note:

   Suppose the required type is (xs:integer | element(e))* and the supplied value is the sequence (<e>22</e>, 23, <f>24</f>). Item coercion is applied independently to each of the three items in this sequence. The first item matches one of the alternatives, namely element(e), so it is returned unchanged as an element node. The second item (the integer 23) also matches one of the alternatives, and is returned unchanged as an integer. The third item does not match any of the alternatives, so coercion is attempted to each one in turn. Coercion to type xs:integer succeeds (by virtue of atomization and untyped atomic conversion), so the final result is the sequence (<e>22</e>, 23, 24)

   Note:

   Suppose the required type is enum("red", "green", "blue") and the supplied value is "green". The enumeration type is defined as a choice item type whose alternatives are singleton enumerations, so the rules are applied first to the type enum("red") (which fails), and then to the type enum("green") (which succeeds). The strings in an enumeration type are required to be distinct so the order of checking is in this case immaterial. The supplied value will be accepted, and will be relabeled if necessary as an instance of xs:string.

   Note:

   Schema-defined union types behave in exactly the same way as choice item types.

3. If R is an atomic type and J is an atomic item, then:

   1. If J is an instance of R then it is used unchanged.

   2. If J is an instance of type xs:untypedAtomic then:

      1. If R is namespace-sensitive then a type error [err:XPTY0117] is raised.

      2. Otherwise, J is cast to type R.

4. If there is an entry (from, to) in the following table such that J is an instance of from, and to is R, then J is cast to type R.

   Implicit Casting

   from	to
   xs:decimal	xs:double
   xs:double	xs:decimal
   xs:decimal	xs:float
   xs:float	xs:decimal
   xs:float	xs:double
   xs:double	xs:float
   xs:string	xs:anyURI
   xs:anyURI	xs:string
   xs:hexBinary	xs:base64Binary
   xs:base64Binary	xs:hexBinary

   Note:

   The item type in the to column must match R exactly; however, J may belong to a subtype of the type in the from column.

   For example, an xs:NCName will be cast to type xs:anyURI, but an xs:anyURI will not be cast to type xs:NCName.

   Similarly, an xs:integer will be cast to type xs:double, but an xs:double will not be cast to type xs:integer.

5. If R is an singleton enumeration type and J is an instance of xs:untypedAtomic or xs:anyURI, then J is cast to type xs:string.

   Note:

   The effect of this rule, when taken in conjunction with the rules above regarding atomization and choice item types, is that when the required type is based on an enumeration type, for example enum("red", "green", "blue")*, the supplied value can be, in this example:

   • AnThe empty sequence.

   • The string "red".

   • An untyped node whose string value is "red".

   • A list-valued node whose typed value contains zero or more strings (or xs:anyURI values), each of which is codepoint-equal to one of "red", "green", or "blue".

   • The xs:anyURI value "red".

   • An array with zero or more members each of which is codepoint-equal to one of "red", "green", or "blue".

   • A JNode whose ·content· property is any of the above.

6. If R is derived from some primitive atomic type P, then J is relabeled as an instance of R if it satisfies all the following conditions:

   • J is an instance of P.

   • J is not an instance of R.

   • The datum^DM of J is within the value space of R.

   Relabeling an atomic item changes the type annotation but not the datum^DM. For example, the xs:integer value 3 can be relabeled as an instance of xs:unsignedByte, because the datum is within the value space of xs:unsignedByte.

   Note:

   Relabeling is not the same as casting. For example, the xs:decimal value 10.1 can be cast to xs:integer, but it cannot be relabeled as xs:integer, because its datum not within the value space of xs:integer.

   Note:

   The effect of this rule is that if, for example, a function parameter is declared with an expected type of xs:positiveInteger, then a call that supplies the literal value 3 will succeed, whereas a call that supplies -3 will fail.

   This differs from previous versions of this specification, where both these calls would fail.

   This change allows the arguments of existing functions to be defined with a more precise type. For example, the $position argument of array:get could be defined as xs:positiveInteger rather than xs:integer.

   Note:

   If T is a union type with members xs:negativeInteger and xs:positiveInteger and the supplied value is the sequence (20, -20), then the effect of these rules is that the first item 20 is relabeled as type xs:positiveInteger and the second item -20is relabeled as type xs:negativeInteger.

   Note:

   Promotion (for example of xs:float to xs:double) occurs only when T is a primitive type. Relabeling occurs only when T is a derived type. Promotion and relabeling are therefore never combined.

   Note:

   A singleton enumeration type such as enum("green") is treated as an atomic type derived by restriction from xs:string; so if the xs:string value "green" is supplied in a context where the required type is enum("red", "green", "blue"), the value will be accepted.

7. If J is a JNode^DM and does not match R, then each item in the ·content· of J is coerced to type R by applying the coercion rules recursively.

   Note:

   For example, if $A is an array and the members of the array are maps, then $A/child::* returns a sequence of JNodes that encapsulate maps, and the average size of these maps can be obtained using the expression avg($A/child::* ! map:size(.)). The first argument of map:size does not accept a JNode directly, but it does (in effect) accept a JNode that encapsulates a map.

8. If R is an ArrayType other than array(*) and J is an array, then J is converted to a new array by converting each member to the required member type by applying the coercion rules recursively.

   Note:

   For example, if the required type is array(xs:double) and the supplied value is [ 1, 2 ], the array is converted to [ 1e0, 2e0 ].

9. If R is a MapType other than map(*) and J is a map, then J is converted to a new map as follows:

   1. Each key in the supplied map is converted to the required map key type by applying the coercion rules. If the resulting map would contain duplicate keys, a type error is raised [err:XPTY0004].

   2. The corresponding value is converted to the required map value type by applying the coercion rules recursively.

   3. The order of entries in the map remains unchanged.

   Note:

   For example, if the required type is map(xs:string, xs:double) and the supplied value is { "x": 1, "y": 2 }, the map is converted to { "x": 1e0, "y": 2e0 }.

   Note:

   Duplicate keys can occur if the value space of the target type is more restrictive than the original type. For example, an error is raised if the map { 1.2: 0, 1.2000001: 0 }, which contains two keys of type xs:decimal, is coerced to the type map(xs:float, xs:integer).

10. If R is a RecordType and J is a map, then J is converted to a new map as follows:

    1. The keys in the supplied map are unchanged.

    2. In any map entry whose key is equal to the name of one of the field declarations in R (under the rules of the atomic-equal function), the corresponding value is converted to the required type defined by that field declaration, by applying the coercion rules recursively (but with XPath 1.0 compatibility mode treated as false).

    3. The order of entries in the map is changed: entries whose keys correspond to the names of field declarations in R appear first, in the order of the corresponding field declarations, and (if the record type is extensible) other entries then follow retaining their relative order in J.

    Note:

    For example, if the required type is record(longitude as xs:double, latitude as xs:double) and the supplied value is { "latitude": 53.2, "longitude": 0 }, then the map is converted to { "longitude": 0.0e0, "latitude": 53.2e0 }.

11. If R is a TypedFunctionType and J is a function item, then function coercion is applied to J.

    Note:

    Function coercion applies even if J is already an instance of R.

    Maps and arrays are functions, so function coercion applies to them as well.

12. If, after the above conversions, the resulting item does not match the expected item type R according to the rules for SequenceType Matching, a type error is raised [err:XPTY0004].

    Note:

    Under the general rules for type errors (see 2.5.1 Kinds of Errors), a processor may report a type error during static analysis if it will necessarily occur when the expression is evaluated. For example, the function call fn:abs("beer") will necessarily fail when evaluated, because the function requires a numeric value as its argument; this may be detected and reported as a static error.

3.4.3 Implausible Coercions

An expression is deemed to be implausible [err:XPTY0006] if the static type of the expression, after applying all necessary coercions, is substantively disjoint with the required type T.

[Definition: Two sequence types are deemed to be substantively disjoint if (a) neither is a subtype of the other (see 3.3.1 Subtypes of Sequence Types) and (b) the only values that are instances of both types are one or more of the following:

• The empty sequence, ().

• The empty map^DM, {}.

• The empty array^DM, [].

]

For example, supplying a value whose static type is xs:integer* when the required type is xs:string* is implausible, because it can succeed only in the special case where the actual value supplied is an empty sequence.For example, supplying a value whose static type is xs:integer* when the required type is xs:string* is implausible, because it can succeed only in the special case where the actual value supplied is the empty sequence.For example, supplying a value whose static type is xs:integer* when the required type is xs:string* is implausible, because it can succeed only in the special case where the actual value supplied is anthe empty sequence.

Examples of implausible coercions include the following:

• round(timezone-from-time($now)). The result of fn:timezone-from-time is of type xs:dayTimeDuration?, which is substantively disjoint with the required type of fn:round, namely xs:numeric?.

• function($x as xs:integer) as array(xs:string) { array { 1 to $x } }. The type of the function body is array(xs:integer), which is substantively disjoint with the required type array(xs:string): the function can succeed only in the exceptional case where the function body delivers an empty array^DM.

3.4.4 Function Coercion

Function coercion is a transformation applied to function items during application of the coercion rules. [Definition: Function coercion wraps a function item in a new function whose signature is the same as the expected type. This effectively delays the checking of the argument and return types until the function is called.]

Given a function F, and an expected function type T, function coercion proceeds as follows:

1. If F has higher arity than T, a type error is raised [err:XPTY0004]

2. If F has lower arity than T, then F is wrapped in a new function that declares and ignores the additional argument; the following steps are then applied to this new function.

   For example, if T is function(node(), xs:boolean) as xs:string, and the supplied function is fn:name#1, then the supplied function is effectively replaced by function($n as node(), $b as xs:boolean) as xs:string { fn:name($n) }

   Note:

   This mechanism makes it easier to design versatile and extensible higher-order functions. For example, in previous versions of this specification, the second argument of the fn:filter function expected an argument of type function(item()) as xs:boolean. This has now been extended to function(item(), xs:integer) as xs:boolean, but existing code continues to work, because callback functions that are not interested in the value of the second argument simply ignore it.

3. A type error is raised [err:XPTY0004] if, for any parameter type, or for the result type, the relevant type in the signature of the supplied function and the relevant type in the expected function type are substantively disjoint.

   For example, the types xs:integer and xs:string are substantively disjoint, so a function with signature function(xs:integer) as xs:boolean cannot be supplied where the expected type is function(xs:string) as xs:boolean.

4. Function coercion then returns a new function item with the following properties (as defined in [XDM 4.0] section 8.1 Function Items):

   • name: The name of F(if not absent).

   • identity: A new function identity distinct from the identity of any other function item.

     Note:

     See also 4.6.7 Function Identity.

   • signature: Annotations is set to the annotations of F. TypedFunctionType is set to the expected type.

   • implementation: In effect, a FunctionBody that calls F, passing it the parameters of this new function, in order.

   • nonlocal variable bindings: An empty mapping.

These rules have the following consequences:

• SequenceType matching of the function’s arguments and result are delayed until that function is called.

• When the coerced function is called, the supplied arguments must match the parameter typed defined in T; it is not sufficient to match the parameter types defined in F.

• The coercion rules rules applied to the function’s arguments and result are defined by the SequenceType it has most recently been coerced to. Additional coercion rules could apply when the wrapped function is called.

• If an implementation has static type information about a function, that can be used to type check the function’s argument and return types during static analysis.

• When function coercion is applied to a map or an array, the resulting function is not a map or array, and cannot be used as such. For example, the expression

  let $f as function(xs:integer) as xs:boolean := { 0: false(), 1: true() }
  return $f?0

  raises a type error, because a lookup expression requires the left hand operand to be a map or array, and $f is neither.

• When function types are used as alternatives in a choice item type, the supplied function is coerced to the first alternative for which coercion does not raise a type error. In this situation it is important to write the alternatives in order, with the most specific first.

Since maps and arrays are also functions in XPath 4.0, function coercion applies to them as well. For instance, consider the following expression:

let $m := {
  "Monday" : true(),
  "Wednesday" : false(),
  "Friday" : true()
}
let $days := ("Monday", "Tuesday", "Wednesday", "Thursday", "Friday")
return filter($days, $m)

The map $m is an instance of function(xs:anyAtomicType?) as item()*. When the fn:filter() function is called, the following occurs to the map:

1. The map $m is treated as a function equivalent to map:get($m, ?).

2. The coercion rules result in applying function coercion to this function, wrapping it in a new function (M′) with the signature function(item(), xs:integer) as xs:boolean.

3. When M′ is called by fn:filter(), coercion and SequenceType matching rules are applied to the argument, resulting in an item() value ($a) or a type error.

4. The function map:get($m, ?) is called with $a as the argument; this returns either an xs:boolean or the empty sequence (call the result R).

5. The wrapper function $p applies the coercion rules to R. If R is an xs:boolean the matching succeeds. When it is an empty sequence (in particular, $m does not contain a key for "Tuesday"), a type error is raised [err:XPTY0004], since the expected type is xs:boolean and the actual type is an empty sequence. The wrapper function $p applies the coercion rules to R. If R is an xs:boolean the matching succeeds. When it is the empty sequence (in particular, $m does not contain a key for "Tuesday"), a type error is raised [err:XPTY0004], since the expected type is xs:boolean, which does not allow the empty sequence. The wrapper function $p applies the coercion rules to R. If R is an xs:boolean the matching succeeds. When it is anthe empty sequence (in particular, $m does not contain a key for "Tuesday"), a type error is raised [err:XPTY0004], since the expected type is xs:boolean and the actual type is an, which does not allow the empty sequence.

Consider the following expression:

let $m := {
   "Monday" : true(),
   "Wednesday" : false(),
   "Friday" : true(),
}
let $days := ("Monday", "Wednesday", "Friday")
return filter($days, $m)

In this case the result of the expression is the sequence ("Monday", "Friday"). But if the input sequence included the string "Tuesday", the filter operation would fail with a type error.

declare function local:filter(
  $s as item()*, 
  $p as function(xs:string) as xs:boolean
) as item()* {
  $s[$p(.)]
};

let $f := function($a) { $a mod 2 = 0 }
return local:filter(1 to 10, $f)

3.4.5 Examples of Coercions

This section illustrates the effect of the coercion rules with examples.

4.3.4 Parenthesized Expressions

Parentheses may be used to override the precedence rules. For example, the expression (2 + 4) * 5 evaluates to thirty, since the parenthesized expression (2 + 4) is evaluated first and its result is multiplied by five. Without parentheses, the expression 2 + 4 * 5 evaluates to twenty-two, because the multiplication operator has higher precedence than the addition operator.

Empty parentheses are used to denote anthe empty sequence, as described in 4.8.1 Sequence Concatenation.

4.6.1 Static Function Calls

The static context for an expression includes a set of statically known function definitions. Every function definition in the static context has a name (which is an expanded QName) and an arity range, which is a range of permitted arities for calls on that function. Two function definitions having the same name must not have overlapping arity ranges. This means that for a given static function call, it is possible to identify the target function definition in the static context unambiguously from knowledge of the function name and the number of supplied arguments.

A static function call is bound to a function definition in the static context by matching the name and arity. If the function call has P positional arguments followed by K keyword arguments, then the required arity is P+K, and the static context must include a function definition whose name matches the expanded QName in the function call, and whose arity range includes this required arity. This is the function chosen to be called. The result of the function is obtained by evaluating the expression that forms its implementation, with a dynamic context that provides values for all the declared parameters, initialized as described in 4.6.1.2 Evaluating Static Function Calls below.

Similarly, a named function reference of the form f#N binds to a function definition in the static context whose name matches f where MinP ≤ N and MaxP ≥ N. The result of evaluating a function reference is a function item which can be called using a dynamic function call. Function items are never variadic and their arguments are always supplied positionally. For example, the function reference fn:concat#3 returns a function item with arity 3, which is always called by supplying three positional arguments, and whose effect is the same as a static call on fn:concat with three positional arguments.

The detailed rules for evaluating static function calls and function references are defined in subsequent sections.

4.6.3 Dynamic Function Calls

A dynamic function call consists of a base expression that returns the function and a parenthesized list of zero or more arguments (argument expressions or ArgumentPlaceholders).

A dynamic function call is evaluated as described in 4.6.3.1 Evaluating Dynamic Function Calls.

The following are examples of dynamic function calls:

• This example calls the function contained in $f, passing the arguments 2 and 3:

  $f(2, 3)

• This example fetches the second item from sequence $f, treats it as a function and calls it, passing an xs:string argument:

  $f[2]("Hi there")

• This example calls the function $f passing no arguments, and filters the result with a positional predicate:

  $f()[2]

let $incr := 1
let $f := function($i as xs:decimal) as xs:decimal { $i + $incr }
return $f(5)

let $vat := function() { @vat + @price }
return doc('wares.xml')/shop/article/$vat()

let $vat := function($art) { $art/@vat + $art/@price }
return doc('wares.xml')/shop/article/$vat(.)

let $ctx := doc('wares.xml')/shop/article
let $vat := function() { for $a in $ctx return $a/@vat + $a/@price }
return $vat()

let $vat := function { @vat + @price }
return $vat(doc('wares.xml')/shop/article)

(abs#1, round#1, floor#1, ceiling#1)(3.2)

csv-to-arrays( string-join(("a,b,c", "p,q,r", "x,y,z"), char(10)) ) (2)

4.7.5 Axis Steps

[Definition: An axis step is an instance of the production AxisStep: it is an expression that returns a sequence of GNodes that are reachable from a starting GNode via a specified axis. An axis step has three parts: an axis, which defines the direction of movement for the step, a node test, which selects GNodes based on their properties, and zero or more predicates which are used to filter the results.]

If the context value for an axis step includes a map or array, this is implicitly converted to a JNode as if by applying the fn:jtree function. If, after this conversion, the sequence contains a value that is not a GNode, a type error is raised [err:XPTY0020]. The result of evaluating the axis step is a sequence of zero or more GNodes.

The axis stepS is equivalent to ./S. Thus, if the context value is a sequence containing multiple GNodes, the semantics of a axis step are equivalent to a path expression in which the step is always applied to a single GNode. The following description therefore explains the semantics for the case where the context value is a single GNode, called the origin.

In the abbreviated syntax for a step, the axis can be omitted and other shorthand notations can be used as described in 4.7.8 Abbreviated Syntax.

The unabbreviated syntax for an axis step consists of the axis name and node test separated by a double colon. The result of the step consists of the GNodes reachable from the origin via the specified axis that match the node test. For example, the step child::para selects the para element children of the origin XNode: child is the name of the axis, and para is the name of the element nodes to be selected on this axis. The available axes are described in 4.7.5.1 Axes. The available node tests are described in 4.7.5.2 Node Tests. Examples of steps are provided in 4.7.7 Unabbreviated Syntax and 4.7.8 Abbreviated Syntax.

4.7.7 Unabbreviated Syntax

This section provides a number of examples of path expressions in which the axis is explicitly specified in each step. The syntax used in these examples is called the unabbreviated syntax. In many common cases, it is possible to write path expressions more concisely using an abbreviated syntax, as explained in 4.7.8 Abbreviated Syntax.

These examples assume that the context value is a single node, referred to as the context node.

• child::para selects the para element children of the context node.

• child::(para|bullet) selects the para and bullet element children of the context node.

• child::* selects all element children of the context node.

• child::text() selects all text node children of the context node.

• child::(text()|comment()) selects all text node and comment node children of the context node.

• child::node() selects all the children of the context node. Note that no attribute nodes are returned, because attributes are not children.

• attribute::name selects the name attribute of the context node.

• attribute::* selects all the attributes of the context node.

• parent::node() selects the parent of the context node. If the context node is an attribute node, this expression returns the element node (if any) to which the attribute node is attached.

• descendant::para selects the para element descendants of the context node.

• ancestor::div selects all div ancestors of the context node.

• ancestor-or-self::div selects the div ancestors of the context node and, if the context node is a div element, the context node as well.

• descendant-or-self::para selects the para element descendants of the context node and, if the context node is a para element, the context node as well.

• self::para selects the context node if it is a para element, and otherwise returns an empty sequence.self::para selects the context node if it is a para element, and otherwise returns the empty sequence.self::para selects the context node if it is a para element, and otherwise returns anthe empty sequence.

• self::(chapter|appendix) selects the context node if it is a chapter or appendix element, and otherwise returns an empty sequence.self::(chapter|appendix) selects the context node if it is a chapter or appendix element, and otherwise returns the empty sequence.self::(chapter|appendix) selects the context node if it is a chapter or appendix element, and otherwise returns anthe empty sequence.

• child::chapter/descendant::para selects the para element descendants of the chapter element children of the context node.

• child::*/child::para selects all para grandchildren of the context node.

• / selects the root of the tree that contains the context node, but raises a dynamic error if this root is not a document node.

• /descendant::para selects all the para elements in the same document as the context node.

• /descendant::list/child::member selects all the member elements that have a list parent and that are in the same document as the context node.

• child::para[position() = 1] selects the first para child of the context node.

• child::para[position() = last()] selects the last para child of the context node.

• child::para[position() = last()-1] selects the last but one para child of the context node.

• child::para[position() > 1] selects all the para children of the context node other than the first para child of the context node.

• following-sibling::chapter[position() = 1] selects the next chapter sibling of the context node.

• following-sibling::(chapter|appendix)[position() = 1] selects the next sibling of the context node that is either a chapter or an appendix.

• preceding-sibling::chapter[position() = 1] selects the previous chapter sibling of the context node.

• /descendant::figure[position() = 42] selects the forty-second figure element in the document containing the context node.

• /child::book/child::chapter[position() = 5]/child::section[position() = 2] selects the second section of the fifth chapter of the book whose parent is the document node that contains the context node.

• child::para[attribute::type eq "warning"] selects all para children of the context node that have a type attribute with value warning.

• child::para[attribute::type eq 'warning'][position() = 5] selects the fifth para child of the context node that has a type attribute with value warning.

• child::para[position() = 5][attribute::type eq "warning"] selects the fifth para child of the context node if that child has a type attribute with value warning.

• child::chapter[child::title = 'Introduction'] selects the chapter children of the context node that have one or more title children whose typed value is equal to the string Introduction.

• child::chapter[child::title] selects the chapter children of the context node that have one or more title children.

• child::*[self::chapter or self::appendix] selects the chapter and appendix children of the context node.

• child::*[self::(chapter|appendix)][position() = last()] selects the last chapter or appendix child of the context node.

4.7.8 Abbreviated Syntax

The abbreviated syntax for a step permits the following abbreviations:

1. The attribute axis attribute:: can be abbreviated by @. For example, the expression para[@type = "warning"] is short for child::para[attribute::type = "warning"] and so selects para children with a type attribute with value equal to warning.

2. If the axis name is omitted from an axis step, the default axis is child, with two exceptions: (1) if the NodeTest in an axis step contains an AttributeTest or SchemaAttributeTest then the default axis is attribute; (2) if the NodeTest in an axis step is a NamespaceNodeTestthen the default axis is namespace, but in an implementation that does not support the namespace axis, an error is raised [err:XQST0134].

   Note:

   The namespace axis is deprecated as of XPath 2.0, but is required in some languages that use XPath, including XSLT.

   For example, the path expression section/para is an abbreviation for child::section/child::para, and the path expression section/@id is an abbreviation for child::section/attribute::id. Similarly, section/attribute(id) is an abbreviation for child::section/attribute::attribute(id). Note that the latter expression contains both an axis specification and a node test.

   Similarly, within a JTree rooted at an array, the expression get(1)/parts/get(2)/part-no gets the first member of the top-level array (presumably a map), then the "parts" entry within this map (presumably an array), then the second member of this array (presumably a map), and finally the part-no entry within this map.

   Note:

   The same selection could be made using the lookup expression ?1?parts?2?part-no. The main difference is that path expressions offer more flexibility in being able to navigate around the containing JTree. Also, the lookup expression $a?1 fails if the array index is out of bounds; the path expression $a/get(1) (or $a/*[1]) instead returns an empty sequence.The same selection could be made using the lookup expression ?1?parts?2?part-no. The main difference is that path expressions offer more flexibility in being able to navigate around the containing JTree. Also, the lookup expression $a?1 fails if the array index is out of bounds; the path expression $a/get(1) (or $a/*[1]) instead returns the empty sequence.The same selection could be made using the lookup expression ?1?parts?2?part-no. The main difference is that path expressions offer more flexibility in being able to navigate around the containing JTree. Also, the lookup expression $a?1 fails if the array index is out of bounds; the path expression $a/get(1) (or $a/*[1]) instead returns anthe empty sequence.

   Note:

   An abbreviated axis step that omits the axis name must use a SimpleNodeTest rather than a UnionNodeTest. This means that a construct such as (ul|ol) is treated as an abbreviation for (child::ul|child::ol) rather than child::(ul|ol). Since the two constructs have exactly the same semantics, this is not actually a restriction.

3. A step consisting of .. is short for parent::gnode(). For example (assuming the context item is an XNode), ../title is short for parent::gnode()/child::title and so will select the title children of the parent of the context node.

   Similarly, if $dateOfBirth is a JNode resulting from the expression $map/get("date of birth"), then $dateOfBirth/../gender will select the entry having key "gender" within $map.

   Note:

   The expression ., known as a context value reference, is a primary expression, and is described in 4.3.3 Context Value References.

Here are some examples of path expressions that use the abbreviated syntax. These examples assume that the context value is a single XNode, referred to as the context node:

• para selects the para element children of the context node.

• * selects all element children of the context node.

• text() selects all text node children of the context node.

• @name selects the name attribute of the context node.

• @(id|name) selects the id and name attributes of the context node.

• @* selects all the attributes of the context node.

• para[1] selects the first para child of the context node.

• para[last()] selects the last para child of the context node.

• */para selects all para grandchildren of the context node.

• /book/chapter[5]/section[2] selects the second section of the fifth chapter of the book whose parent is the document node that contains the context node.

• chapter//para selects the para element descendants of the chapter element children of the context node.

• //para selects all the para descendants of the root document node and thus selects all para elements in the same document as the context node.

• //@version selects all the version attribute nodes that are in the same document as the context node.

• //list/member selects all the member elements in the same document as the context node that have a list parent.

• .//para selects the para element descendants of the context node.

• .. selects the parent of the context node.

• ../@lang selects the lang attribute of the parent of the context node.

• para[@type = "warning"] selects all para children of the context node that have a type attribute with value warning.

• para[@type = "warning"][5] selects the fifth para child of the context node that has a type attribute with value warning.

• para[5][@type = "warning"] selects the fifth para child of the context node if that child has a type attribute with value warning.

• chapter[title = "Introduction"] selects the chapter children of the context node that have one or more title children whose typed value is equal to the string Introduction.

• chapter[title] selects the chapter children of the context node that have one or more title children.

• employee[@secretary and @assistant] selects all the employee children of the context node that have both a secretary attribute and an assistant attribute.

• book/(chapter|appendix)/section selects every section element that has a parent that is either a chapter or an appendix element, that in turn is a child of a book element that is a child of the context node.

• If E is any expression that returns a sequence of nodes, then the expression E/. returns the same nodes in document order, with duplicates eliminated based on node identity.

The following examples use abbreviated paths to access data within the JTree obtained by parsing the JSON text:

[
  { "first": "John", 
    "last": "Baker", 
    "date of birth": "2003-04-19", 
    "occupation": "cook"}, 
  { "first": "Mary", 
    "last": "Smith", 
    "date of birth": "2006-08-12", 
    "occupation": "teacher"},                 
]

• get(1)/first returns a JNode whose ·content· is the string "John".

• //first[. = "Mary"]/../last returns a JNode whose ·content· is the string "Smith".

• //first[. = "Mary"]/../get("date of birth") returns a JNode whose ·content· is the string "2006-08-12".

• //*[occupation = "cook"]!`{first} {last}` returns the string "John Baker".

• //*[occupation = "cook"]/following-sibling::*[1]!`{first} {last}` returns the string "Mary Smith".

• //*[last = "Smith"]/../get(1)/last returns the string "Baker".

• //record(first, last, *) ! string(last) returns the sequence of two strings "Baker", "Smith".

4.8.1 Sequence Concatenation

[Definition: A sequence expression is a non-trivial instance of the production rule Expr, that is, an expression containing two or more instances of the production ExprSingle separated by the comma operator.]

The result of a sequence expression is the sequence concatenation of the values of its operands. See

[Definition: A comma operator is a comma used specifically as the operator in a sequence expression.]

Empty parentheses can be used to denote anthe empty sequence.

A sequence may contain duplicate items, but a sequence is never an item in another sequence. When a new sequence is created by concatenating two or more input sequences, the new sequence contains all the items of the input sequences and its length is the sum of the lengths of the input sequences.

[Definition: The sequence concatenation of a number of sequences S₁, S₂, ... S_n is defined to be the sequence formed from the items of S₁, followed by the items from S₂, and so on, retaining order.] The comma operator returns the sequence concatenation of its two operands; repeated application (for example $s1, $s2, $s3, $s4) delivers the sequence concatenation of multiple sequences.

Here are some examples of expressions that construct sequences:

• The result of this expression is a sequence of five integers:

  (10, 1, 2, 3, 4)

• This expression combines four sequences of length one, two, zero, and two, respectively, into a single sequence of length five. The result of this expression is the sequence 10, 1, 2, 3, 4.

  (10, (1, 2), (), (3, 4))

• The result of this expression is a sequence containing all salary children of the context node followed by all bonus children.

  (salary, bonus)

• Assuming that $price is bound to the value 10.50, the result of this expression is the sequence 10.50, 10.50.

  ($price, $price)

4.8.2 Range Expressions

[Definition: A range expression is a non-trivial instance of the production RangeExpr. A range expression is used to construct a sequence of integers.] Each of the operands is converted as though it was an argument of a function with the expected parameter type xs:integer?. If either operand is an empty sequence, or if the integer derived from the first operand is greater than the integer derived from the second operand, the result of the range expression is an empty sequence. If the two operands convert to the same integer, the result of the range expression is that integer. Otherwise, the result is a sequence containing the two integer operands and every integer between the two operands, in increasing order. [Definition: A range expression is a non-trivial instance of the production RangeExpr. A range expression is used to construct a sequence of integers.] Each of the operands is converted as though it was an argument of a function with the expected parameter type xs:integer?. If either operand is the empty sequence, or if the integer derived from the first operand is greater than the integer derived from the second operand, the result of the range expression is the empty sequence. If the two operands convert to the same integer, the result of the range expression is that integer. Otherwise, the result is a sequence containing the two integer operands and every integer between the two operands, in increasing order. [Definition: A range expression is a non-trivial instance of the production RangeExpr. A range expression is used to construct a sequence of integers.] Each of the operands is converted as though it was an argument of a function with the expected parameter type xs:integer?. If either operand is anthe empty sequence, or if the integer derived from the first operand is greater than the integer derived from the second operand, the result of the range expression is anthe empty sequence. If the two operands convert to the same integer, the result of the range expression is that integer. Otherwise, the result is a sequence containing the two integer operands and every integer between the two operands, in increasing order.

The following examples illustrate the semantics:

• 1 to 4 returns the sequence 1, 2, 3, 4

• 10 to 10 returns the singleton sequence 10

• 10 to 1 returns the empty sequence

• -13 to -10 returns the sequence -13, -12, -11, -10

More formally, a range expression is evaluated as follows:

1. Each of the operands of the to operator is converted as though it was an argument of a function with the expected parameter type xs:integer?.

2. If either operand is anthe empty sequence, or if the integer derived from the first operand is greater than the integer derived from the second operand, the result of the range expression is anthe empty sequence.

3. If the two operands convert to the same integer, the result of the range expression is that integer.

4. Otherwise, the result is a sequence containing the two integer operands and every integer between the two operands, in increasing order.

The following examples illustrate the use of range expressions.

(10, 1 to 4)

$input[1 to 4]

$x = (1 to 5) ! . * 0.1

10 to 10

15 to 10

reverse(10 to 15)

4.10.2 String Templates

String templates provide an alternative way of constructing strings. For example, the expression `Pi is { round(math:pi(), 4) }` returns the string "Pi is 3.1416".

A string template starts and ends with U+0060 (GRAVE ACCENT, BACKTICK, `) , popularly known as a back-tick. Between the back-ticks is a string consisting of an sequence of fixed parts and variable parts:

• A variable part consists of an optional XPath expression enclosed in curly brackets ({}): more specifically, a string conforming to the XPath production Expr?.

  Note:

  An expression within a variable part may contain an unescaped U+007B (LEFT CURLY BRACKET, {) or U+007D (RIGHT CURLY BRACKET, }) within a StringLiteral or within a comment.

  The fact that the expression is optional means that the string contained between the curly brackets may be zero-length, may comprise whitespace only, or may contain XPath comments. The effective value in this case is a zero-length string, which is equivalent to omitting the variable part entirely, together with its curly-bracket delimiters.

• A fixed part may contain any characters, except that:

  • The character U+007B (LEFT CURLY BRACKET, {) must be written as {{.

  • The character U+007D (RIGHT CURLY BRACKET, }) must be written as }}.

  • The character U+0060 (GRAVE ACCENT, BACKTICK, `) must be written as ``.

  Following the principles of the “longest token” rule, any occurrence of {{ within the fixed part is interpreted as an escaped left curly bracket. This means that the enclosed expression must not start with U+007B (LEFT CURLY BRACKET, {) : if this is required, the two left curly brackets can be separated by whitespace. For example the string template `{{"key":"{ {1:"yes", 0:"no"}?$condition}"}}` evaluates to the string {"key":"yes"} or {"key":"no"} depending on the value of $condition.

  By contrast, if the enclosed expression ends with U+007D (RIGHT CURLY BRACKET, }) , this can be immediately followed by the closing U+007D (RIGHT CURLY BRACKET, }) delimiter without intervening whitespace.

The result of evaluating a string template is the string obtained by concatenating the expansions of the fixed and variable parts:

• The expansion of a fixed part is obtained by replacing any double curly brackets ({{ or }}) by the corresponding single curly bracket, and replacing doubled back-ticks (``) by a single back-tick.

• The expansion of a variable part containing an expression is as follows:

  1. Atomization is applied to the value of the enclosed expression, converting it to a sequence of atomic items.

  2. If the result of atomization is anthe empty sequence, the result is the zero-length string. Otherwise, each atomic item in the atomized sequence is cast into a string.

  3. The individual strings resulting from the previous step are merged into a single string by concatenating them with a single space character between each pair.

• The expansion of anthe empty variable part (one that contains no expression) is a zero-length string.

For example:

let $greeting := "Hello", $planet := "Mars"
return `{ $greeting }, { $planet }!`

returns "Hello, Mars!".

The expression:

let $long-months := (1, 3, 5, 7, 8, 10, 12)
return `The months with 31 days are: { $long-months }.`

returns "The months with 31 days are: 1 3 5 7 8 10 12.".

In XQuery, the token ``[ is recognized as the start of a StringConstructor, under the “longest token” rule (see A.3 Lexical structure). This means that the construct ``[1] is not recognized as a StringTemplate followed by a predicate. Although the token ``[ is not used in XPath, it is reserved for compatibility reasons, and must be rejected as syntactically invalid. In the unlikely event that an empty StringTemplate followed by a predicate is wanted, whitespace or parentheses can be used to avoid the tokenization problem.

4.11.1 Value Comparisons

The value comparison operators are eq, ne, lt, le, gt, and ge. Value comparisons are used for comparing single atomic items.

The first step in evaluating a value comparison is to evaluate its operands. The order in which the operands are evaluated is implementation-dependent. Each operand is evaluated by applying the following steps, in order:

1. Atomization is applied to each operand. The result of this operation is called the atomized operand.

2. If either or both of the atomized operands is anthe empty sequence, the result of the value comparison is anthe empty sequence, and the implementation need not evaluate the other operand or apply the operator. However, an implementation may choose to evaluate the other operand and may raise an error if evaluation fails.

3. If an atomized operand is a sequence of length greater than one, a type error is raised [err:XPTY0004].

4. If both operands are instances of xs:numeric, and if either or both of the atomized operands is NaN, then the result is false if the operator is eq, lt, gt, le, or ge, but true if the operator is ne.

   Note:

   When an operand is NaN, the effect of a value comparison expression differs from the result of the fn:compare function.

5. The function fn:compare is then called, supplying the two atomized operands as the first two arguments. The collation used by fn:compare is the default collation from the static context, and the implicit timezone used by the function is the implicit timezone from the dynamic context.

   Note:

   The effect of this rule is that xs:untypedAtomic values (which typically result from atomizing a node) are treated as strings.

6. If fn:compare raises an error (typically because the two operands belong to different type families^DM), then the value comparison fails with that error.

7. The result of the fn:compare function determines the result of the value comparison, according to the following table:

   Result of a Value Comparison

   Result of fn:compare	eq	ne	lt	le	gt	ge
   -1	false	true	true	true	false	false
   0	true	false	false	true	false	true
   +1	false	true	false	false	true	true

Here are some examples of value comparisons:

• The following comparison atomizes the node(s) that are returned by the expression $book/author. The comparison is true only if the result of atomization is the value "Kennedy" as an instance of xs:string or xs:untypedAtomic. If the result of atomization is an empty sequence, the result of the comparison is an empty sequence. If the result of atomization is a sequence containing more than one value, a type error is raised [err:XPTY0004].The following comparison atomizes the node(s) that are returned by the expression $book/author. The comparison is true only if the result of atomization is the value "Kennedy" as an instance of xs:string or xs:untypedAtomic. If the result of atomization is the empty sequence, the result of the comparison is the empty sequence. If the result of atomization is a sequence containing more than one value, a type error is raised [err:XPTY0004].The following comparison atomizes the node(s) that are returned by the expression $book/author. The comparison is true only if the result of atomization is the value "Kennedy" as an instance of xs:string or xs:untypedAtomic. If the result of atomization is anthe empty sequence, the result of the comparison is anthe empty sequence. If the result of atomization is a sequence containing more than one value, a type error is raised [err:XPTY0004].

  $book1/author eq "Kennedy"

• The following comparison is true because atomization converts an array to its member sequence:

  [ "Kennedy" ] eq "Kennedy"

• The following path expression contains a predicate that selects products whose weight is greater than 100. For any product that does not have a weight subelement, the value of the predicate is the empty sequence, and the product is not selected. This example assumes that weight is a validated element with a numeric type.

  //product[weight gt 100]

• The following comparison is true if my:hatsize and my:shoesize are both user-defined types that are derived by restriction from a primitive numeric type:

  my:hatsize(5) eq my:shoesize(5)

• The following comparison is true. The eq operator compares two QNames by performing codepoint-comparisons of their namespace URIs and their local names, ignoring their namespace prefixes.

  QName("http://example.com/ns1", "this:color") eq
  QName("http://example.com/ns1", "that:color")

• The following comparison is false. The xs:double value 1.1e0 is converted to type xs:decimal, giving the result 1.100000000000000088817841970012523233890533447265625, which is not equal to the xs:decimal value 1.1.

  1.1 eq 1.1e0

  Note:

  This is incompatible with previous versions, which converted both operands to xs:double before comparing them. This change has been made because there are contexts (such as sorting and grouping) where it is important that comparison results should be transitive, and this was not previously the case.

4.11.3 GNode Comparisons

GNode comparisons are used to compare two GNodes (that is, XNodes or JNodes^DM), by their identity or by their document order. The result of a GNode comparison is defined by the following rules:

1. The operands of a GNode comparison are evaluated in implementation-dependent order.

2. If either operand is anthe empty sequence, the result of the comparison is anthe empty sequence, and the implementation need not evaluate the other operand or apply the operator. However, an implementation may choose to evaluate the other operand in order to determine whether it raises an error.

3. Each operand must be either a single GNode or anthe empty sequence; otherwise a type error is raised [err:XPTY0004].

4. A comparison with the is operator is true if the values of two operands are the same GNode; otherwise it is false. See [XDM 4.0] for the definition of GNode identity.

5. A comparison with the is-not operator is false if the values of two operands are the same GNode; otherwise it is true. See [XDM 4.0] for the definition of GNode identity.

6. A comparison with the << or precedes operator returns true if the left operand GNode precedes the right operand GNode in document order; otherwise it returns false.

7. A comparison with the >> or follows operator returns true if the left operand GNode follows the right operand GNode in document order; otherwise it returns false.

8. A comparison with the precedes-or-is operator returns true if the left operand GNode precedes the right operand GNode in document order or if the values of two operands are the same GNode; otherwise it returns false.

9. A comparison with the follows-or-is operator returns true if the left operand GNode follows the right operand GNode in document order or if the values of two operands are the same GNode; otherwise it returns false.

Here are some examples of GNode comparisons:

• The following comparison is true only if the left and right sides each evaluate to exactly the same single node:

  /books/book[isbn = "1558604820"] is /books/book[call = "QA76.9 C3845"]

• The following comparison is true only if the node identified by the left side occurs before the node identified by the right side in document order:

  /transactions/purchase[parcel = "28-451"] << /transactions/sale[parcel = "33-870"]

• The following comparison is true only if the first integer among the members of an array precedes the first string. This expression compares two JNodes:

  let $A := ["Q", 3, "E", "R", "T", 5, "Y"]
  return $A ? child::type(xs:integer)[1] precedes $A ? child::type(xs:string)[1]