As noted in 2.1.2 Values, every value in XPath 4.0 is regarded as a sequence of zero, one, or more items. The type system of XPath 4.0, described in this section, classifies the kinds of value that the language can handle, and the operations permitted on different kinds of value.
The type system of XPath 4.0 is related to the type system of [XML Schema 1.0] or [XML Schema 1.1] in two ways:
atomic items in XPath 4.0 (which are one kind of item) have atomic types such as xs:string, xs:boolean, and xs:integer. These types are taken directly from their definitions in [XML Schema 1.0] or [XML Schema 1.1].
Nodes (which are another kind of item) have a property called a type annotation which determines the type of their content. The type annotation is a schema type. The type annotation of a node must not be confused with the item type of the node. For example, an element <age>23</age> might have been validated against a schema that defines this element as having xs:integer content. If this is the case, the type annotation of the node will be xs:integer, and in the XPath 4.0 type system, the node will match the item typeelement(age, xs:integer).
This chapter of the specification starts by defining sequence types and item types, which describe the range of values that can be bound to variables, used in expressions, or passed to functions. It then describes how these relate to schema types, that is, the simple and complex types defined in an XSD schema.
Note:
In many situations the terms item type and sequence type are used interchangeably to refer either to the type itself, or to the syntactic construct that designates the type: so in the expression $x instance of xs:string*, the construct xs:string* uses the SequenceType syntax to designate a sequence type whose instances are sequences of strings. When more precision is required, the specification is careful to use the terms item type and sequence type to refer to the actual types, while using the production names ItemType and SequenceType to refer to the syntactic designators of these types.
[Definition: An item type is a type that can be expressed using the ItemType syntax, which forms part of the SequenceType syntax. Item types match individual items.]
Note:
While this definition is adequate for the purpose of defining the syntax of XPath 4.0, it ignores the fact that there are also item types that cannot be expressed using XPath 4.0 syntax: specifically, item types that reference an anonymous simple type or complex type defined in a schema. Such types can appear as type annotations on nodes following schema validation.
In most cases, the set of items matched by an item type consists either exclusively of atomic items, exclusively of nodes, or exclusively of function itemsDM. Exceptions include the generic types item(), which matches all items, xs:error, which matches no items, and choice item types, which can match any combination of types.
[Definition: An item type designator is a syntactic construct conforming to the grammar rule ItemType. An item type designator is said to designate an item type.]
Note:
Two item type designators may designate the same item type. For example, element() and element(*) are equivalent, as are attribute(A) and attribute(A, xs:anySimpleType).
Lexical QNames appearing in an item type designator are expanded using the default type namespace rule. Equality of QNames is defined by the eq operator.
This section defines the syntax and semantics of different ItemTypes in terms of the values that they match.
Note:
For an explanation of the EBNF grammar notation (and in particular, the operators ++ and **), see A.1 EBNF.
An item type designator written simply as an EQName (that is, a TypeName) is interpreted as follows:
If the name is written as a lexical QName, then it is expanded using the default type namespace rule.
If the expanded name matches a named item type in the static context, then it is taken as a reference to the corresponding item type. The rules that apply are the rules for the expanded item type definition.
Otherwise, it must match the name of a type in the in-scope schema types in the static context: specifically, an atomic type or a pure union type. See 3.5 Schema Types for details.
If the name cannot be resolved to a type, a static error is raised [err:XPST0051].
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.
An ArrayType designates an item type that either matches all arrays, or that matches arrays whose members are constrained to a specific type.
An array(*) matches any array.
The TypedArrayTypearray(X) matches any array in which every array member matches the SequenceTypeX.
Examples:
[ 1, 2 ] instance array(*) returns true()[ 1, 2 ] instance of array(*) returns true()[ 1, 2 ] instance of array(*) returns true()
[] instance of array(xs:string) returns true()
[ "foo" ] instance of array(xs:string) returns true()
[ "foo" ] instance of array(xs:integer) returns false()
[ (1, 2), (3, 4) ] instance of array(xs:integer) returns false()
[ (1, 2), (3, 4) ] instance of array(xs:integer+) returns true()
[ [ 1, 2 ], [ 3, 4 ] ] instance of array(array(xs:integer+)) returns true()
An array also matches certain other item types, including:
An array that matches array(T) also matches the function type function(xs:integer) as T.
Note:
To understand this rule, consider the use of an array $A in a function call $A($I), which is equivalent to the function call array:get($A, $I). This function accepts any integer for the argument $I, and the result will either be an instance of T, or an error.
The transitivity rules for item type matching mean that if an item A matches a type T, and T is a subtype of U, then A also matches type U. So the fact that an array of strings (array(xs:string)) matches function(xs:integer) as xs:string means that it will also match other function types such as function(xs:long) as item()*.
Furthermore, the rules for function coercion mean that any array can be supplied as a value in a context where it does not actually match the required function type, but can be coerced to a function that does. For example an array of type array(node()) can be coerced to a function of type function(xs:integer) as element(); in this situation a type error will occur only if a call on the function actually returns a node that is not an element node.
Rules defining whether one array type is a subtype of another are given in 3.3.2.7 Subtyping Arrays.