XQuery 1.0 and XPath 2.0 Formal Semantics

2.1.1 Notations from grammar productions

Grammar productions are used to describe "objects" (values, types, [XPath/XQuery] expressions, etc.) manipulated by the Formal Semantics. The Formal Semantics makes use of several kinds of grammar productions: productions from the [XPath/XQuery] grammar itself, productions for a subset of the [XPath/XQuery] language called the XQuery Core which is used throughout this document, and other productions used for formal specification only such as for the XQuery type system.

XQuery grammar productions describe the XQuery language and expressions. XQuery productions are identified by a number, which corresponds to their number in the [XQuery 1.0: An XML Query Language] document, and are marked with "(XQuery)". For instance, the following production describes FLWOR expressions in XQuery.

[For/FLWOR] Expressions

For the purpose of this document, the differences between the XQuery 1.0 and the XPath 2.0 grammars are mostly irrelevant. By default, this document uses XQuery 1.0 grammar productions. Whenever the grammar for XPath 2.0 differs from the one for XQuery 1.0, the corresponding XPath 2.0 productions are also given. XPath productions are identified by a number, which corresponds to their number in [XML Path Language (XPath) 2.0], and are marked with "(XPath)". For instance, the following production describes for expressions in XPath.

[For/FLWOR] Expressions

XQuery Core grammar productions describe the XQuery Core. The Core grammar is given in [A Normalized core grammar]. Core productions are identified by a number, which corresponds to their number in [A Normalized core grammar], and are marked with "(Core)". For instance, the following production describes the simpler form of the "FLWOR" expression in the XQuery Core.

Core FLWOR Expressions

The Formal Semantics manipulates "objects" (values, types, expressions, etc.) for which there is no existing grammar production in the [XQuery 1.0: An XML Query Language] document. In these cases, specific grammar productions are introduced. Notably, additional productions are used to describe values in the [Data Model], and to describe the [XPath/XQuery] type system. Formal Semantics productions are identified by a number, and are marked by "(Formal)". For instance, the following production describes global type definitions in the [XPath/XQuery] type system.

Type Definitions

Note that grammar productions that are specific to the Formal Semantics (i.e., marked with "(Formal)") are not part of [XPath/XQuery]. They are not accessible to the user and are only used in the course of defining the languages' semantics.

Grammar non-terminals are used extensively in this document to represent objects in judgments (see the next section). As a convenience, non-terminals used in judgments link to the appropriate grammar production.

2.1.2 Notations for judgments

The basic building block of the formal specification is called a judgment. A judgment expresses whether a property holds or not.

For example:

Notation

The judgment

holds if the object Object is a positive integer.

A judgment may hold (if it is true) or not hold (if it is false). For instance '1 is a positive integer' holds and '-1 is a positive integer' does not hold.

Notation

Here are two other example judgments.

The judgment

holds if the expression Expr yields (or evaluates to) the value Value.

The judgment

holds if the expression Expr has the type Type.

Most other judgments used in this document are short English sentences intended to reflect their meaning, and written in bold fonts. For instance, the judgment

holds if PrincipalNodeKind is the principal node kind for the axis Axis.

A judgment can contain symbols and patterns.

Symbols are purely syntactic and are used to write the judgment itself. In general, symbols in a judgment are chosen to reflect its meaning. For example, 'is beautiful', '=>' and ':' are symbols, the second and third of which should be read "yields", and "has type" respectively.

Patterns are used to represent objects that can be constructed from a given grammar production. In patterns, italicized words correspond to non-terminals in the grammar. The name of those non-terminals is significant, and may be instantiated only to an "object" (a value, a type, an expression, etc.) that can be substituted legally for that non-terminal. For example, 'Expr' is a pattern that stands for every [XPath/XQuery] expressions, 'Expr₁ + Expr₂' is a pattern that stands for every addition expression, 'element a { Value }' is a pattern that stands for every value in the [XPath/XQuery] data model that is an 'a' element.

Non-terminals in a pattern may appear with subscripts (e.g. Expr₁, Expr₂) to distinguish different instances of the same sort of pattern. In some cases, non-terminals in a pattern may have a name that is not exactly the name of that non terminal, but is based on it. For instance, a BaseTypeName is a pattern that stands for a type name, as would TypeName, or TypeName₂. This usage is limited, and only occurs to improve the readability of some of the inference rules.

When instantiating the judgment, each pattern must be instantiated to an appropriate sort of "object" (value, type, expression, etc). For example, '3 => 3' and '$x+0 => 3' are both instances of the judgment 'Expr => Value'. Note that in the first judgment, '3' corresponds to both the expression '3' (on the left-hand side of the => symbol) and to the value '3' (on the right-hand side of the => symbol).

In some cases, inference rules may need to use the fact that a certain judgment does not hold. not(Judgment) holds iff Judgment does not hold.

In some cases, a pattern may be instantiated to a value within a finite set of pre-determined values. We may write that set of possible values using the in judgment. For instance, the judgment

holds if the pattern Color has either the value blue or the value green.

2.1.3 Notations for environments

An environment component is a dictionary that maps a symbol (e.g., a function name or a variable name) to an "object" (e.g., a function body, a type, a value). One can access information in an environment component or update it.

If "envComp" is an environment component, then "envComp(symbol)" denotes the "object" to which symbol is mapped. The notation is intentionally similar to function application, because an environment component can be considered a function from the argument symbol to the "object" to which the symbol is mapped.

This document uses environments that group related environment components. If "env" is an environment containing the environment component "envComp", that environment component is denoted "env.envComp". The value that symbol is mapped to in that environment component is denoted "env.envComp(symbol)".

The two main environments used in the Formal Semantics are: a dynamic environment (dynEnv), which models the [XPath/XQuery]'s dynamic context, and a static environment (statEnv), which models the [XPath/XQuery]'s static context. Both are defined in [3.1 Expression Context].

For example, dynEnv.varValue denotes the dynamic environment component that maps variables to values and dynEnv.varValue(Variable) denotes the value of the variable Variable in the dynamic context.

Environments are used in a judgment to capture some of the context in which the judgment is computed, and most judgments are computed assuming that some environment is given. This assumption is denoted by prefixing the judgment with "env |-". The "|-" symbol is called a "turnstile" and is used in almost all inference rules.

For instance, the judgment

is read as: Assuming the dynamic environment dynEnv, the expression Expr yields the value Value.

Environments can be updated, using the following notation:

• "env + envComp(symbol => object) " denotes the new environment that is identical to env except that the environment component envComp has been updated to map symbol to object. The notation symbol => object indicates that symbol is mapped to object in the new environment.

• In case the environment component contains only a constant value (e.g., the ordering mode which can only be either ordered or unordered), the following notation is used to set its value. "env + envComp( object ) ".

• The following shorthand is also allowed: "env + envComp( symbol₁ => object₁ ; ... ; symbol_n => object_n ) " in which each symbol is mapped to a corresponding object in the new environment.

  This notation is equivalent to nested updates, as in " (env + envComp( symbol₁ => object₁) + ... ) + env(symbol_n => object_n)".

Updating an environment creates a copy of the original environment and overrides any previous binding that might exist for the same name and the same component in that environment. Updating the environment is used to capture the scope of a symbol (e.g., for variables, namespace prefixes, etc). For instance, in the following expression

  let $x := 1 return
  let $x := $x + 2 return
  $x - 3

each let expression changes the dynamic context by binding a new variable to a new value. Each different context is represented by a different environment. The original environment, in which the expression 1 is evaluated, does not contain any binding for variable $x. This environment is updated a first time with a binding of variable $x to the value 1, and this environment is used for the evaluation of the expression $x + 2. Then it is updated a second time with a binding of variable $x to the value 3, and this environment is used for the evaluation of the expression $x - 3.

Also, note that there are no operations to remove entries from environments. This is never necessary as updating an environment effectively creates a new extended copy of the original environment, leaving the original environment accessible wherever it is in scope along with the updated copy.

2.1.4 Notations for inference rules

Inference rules are used to specify how to infer whether a given judgment holds or not. Inference rules express the logical relation between judgments and describe how complex judgments can be concluded from simpler premise judgments.

A logical inference rule is written as a collection of premises and a conclusion, written respectively above and below a dividing line, as follows:

All premises and the conclusion are judgments. From a logical point of view, an inference rule is a deduction that if the premises hold, then the conclusion holds as well. In that sense, the previous inference rule has a similar meaning as the following logical statement.

IF premise₁

AND ...

AND premise_n

THEN conclusion

Here is a simple example of inference rule, which uses specific instances of the example judgment 'Expr => Value' from above:

This inference rule expresses the following property: if the variable expression '$x' yields the value '0', and the literal expression '3' yields the value '3', then the expression '$x + 3' yields the value '3'.

An inference rule may have no premises above the line, which means that the expression below the line always holds. For instance:

This inference rule expresses the following property: evaluating the literal expression '3' always yields the value '3'.

The two above rules are expressed in terms of specific expressions and values, but usually rules are more abstract. That is, the judgments are not fully instantiated. Here is a rule that says that for any variable Variable that yields the integer value Integer, adding '0' yields the same integer value:

Each occurrence of a given pattern in a particular inference rule must be instantiated to the same "object" within the entire rule. This means that one can talk about "the value of Variable" instead of the value bound to the first (second, etc) occurrence of VarRef.

Here is an example of a rule occurring later in this document.

This rule is read as follows: if two expressions Expr₁ and Expr₂ are known to have the static types Type₁ and Type₂ (the two premises above the line), then it is the case that the sequence expression "Expr₁ , Expr₂" has the static type "Type₁, Type₂", which is the sequence of types Type₁ and Type₂. Note that this inference rule does not modify the static environment.

The following rule defines the static semantics of a "let" expression. The binding of the new variable is captured by an update to the varType component of the original static environment.

This rule is read as follows: First, because the variable is a QName, it is first expanded into an expanded QName. Second, the type Type₁ for the "let" input expression Expr₁ is computed. Then the "let" variable with expanded name, expanded-QName with type Type₁ is added into the varType component of the static environment statEnv. Finally, the type Type₂ of Expr₂ is computed in that new environment.

2.1.5 Putting it together

In isolation, each inference rule describes a fragment of the semantics for a given judgment. Put together, inference rules describe possible inferences that can be used to decide whether that a particular judgment hold.

For a given judgment, and a set of inference rules, if that judgment can be inferred to be true, the inference succeeds. In most cases, the inference will proceed by proving intermediate judgments, following the consequences from one judgment to the next by applying successive inference rules.

Such inference is a mechanism which can be used to describe both static type analysis and dynamic evaluation. More specifically, performing static typing consists in proving that the following judgment holds for a given expression Expr.

If the judgment holds for a given type Type, this type is a possible static type for the expression. If there exists no type for which this judgment holds, then static typing fails and a static type error is returned to the user.

Consider the following expression.

  fn:count((1,2,3))

Using the static typing rules given for expressions in the rest of this document, one can deduce that the expression is of type xs:integer through the following inference.

  statEnv |- 1 : xs:integer  (from typing of literals)
  statEnv |- 2 : xs:integer  (from typing of literals)
  --------------------------------------------------- (sequence)
    statEnv |- 1,2 : xs:integer, xs:integer
    statEnv |- 3 : xs:integer
    ----------------------------------------------------- (sequence)
    statEnv |- 1,2,3 : xs:integer, xs:integer, xs:integer

    declare function fn:count($x as item()*) as xs:integer
    statEnv |- xs:integer,xs:integer,xs:integer <: item*
    ---------------------------------------------------------- (function call)
    statEnv |- fn:count((1,2,3)) : xs:integer

Conversly, consider the following expression.

  fn:nilled((1,2,3))

Using the static typing rules given for expressions in the rest of this document, one can apply inference rules up to the following point.

    ....
    ----------------------------------------------------- (sequence)
    statEnv |- 1,2,3 : xs:integer, xs:integer, xs:integer

However, there is no rule that can infer the type of fn:nilled((1,2,3)), because the static typing rules for function calls will only hold if the type of the function parameters is a subtype of the expected type. However, here (xs:integer,xs:integer,xs:integer) is not a node type, which is the expected type for the function fn:nilled.

Note that in some cases, the inference can only proceed through the appropriate changes to the environment. For instance, consider the following expression.

  let $x := 1 return ($x,$x)

Using the static typing rules given for expressions in the rest of this document, one can deduce that the expression is of type (xs:integer,xs:integer) through the following inference.

statEnv0.varType = ()

  -------------------------- (literal)
  statEnv0 |- 1 : xs:integer

statEnv1 = statEnv0 + varType($x => xs:integer)

     statEnv1.varType($x) = xs:integer
     --------------------------------- (variable reference)
     statEnv1 |- $x : xs:integer

     statEnv1.varType($x) = xs:integer
     --------------------------------- (variable reference)
     statEnv1 |- $x : xs:integer

     ------------------------------------------- (sequence)
     statEnv1 |- ($x,$x) : xs:integer,xs:integer

  -------------------------------------------------------------- (let)
  statEnv0 |- let $x := 1 return ($x,$x) : xs:integer,xs:integer

This example illustrates how each rule is applied to individual sub-expressions, and how the environment is used to maintain the relevant context information.

2.3.1 Formal values

A value is a sequence of zero or more items. An item is either an atomic value or a node.

An atomic value is a value in the value space of an atomic type, labeled with the name of that atomic type. An atomic type is either a primitive or derived atomic type according to XML Schema [Schema Part 2], xdt:untypedAtomic, or xdt:anyAtomicType.

A node is either an element, an attribute, a document, a text, a comment, or a processing-instruction node.

Element nodes have a type annotation^XQ and contain a complex value or a simple value. Attribute nodes have a type annotation^XQ and contain a simple value. Text nodes always contain one string value of type xdt:untypedAtomic, therefore the corresponding type annotation is omitted in the formal notation of a text node. Document nodes do not have a type annotation and contain a sequence of element, text, comment, or processing-instruction nodes.

A simple value is a sequence of atomic values.

A complex value is a sequence of attribute nodes followed by a sequence of element, text, comment, or processing-instruction nodes.

A type annotation^XQ can be either the QName of a declared type or an anonymous type. An anonymous type corresponds to an XML Schema type for which the schema writer did not provide a name. Anonymous type names are not visible to the user, but are generated during schema validation and used to annotate nodes in the data model. By convention, anonymous type names are written using the fs: Formal Semantics prefix: fs:anon₀, fs:anon₁, etc.

Formal values are defined by the following grammar.

Values

Notation

In that grammar, "String" indicates the value space of xs:string, "Decimal" indicates the value space of xs:decimal, etc.

Element (resp. attributes) without type annotations, are assumed to have the type annotation xs:anyType (resp. xs:anySimpleType). Atomic values without type annotations, are assumed to have a type annotation which is the base type for the corresponding value. For instance, "Hello, World!" is equivalent to "Hello, World!" of type xs:string.

Untyped elements (e.g., from well-formed documents) have the type annotation^XQ xdt:untyped, untyped attributes have the type annotation^XQ xdt:untypedAtomic, and untyped atomic values have the type annotation^XQ xdt:untypedAtomic.

An element has an optional "nilled" marker. This marker is present only if the element has been validated against an element type in the schema which is "nillable", and the element has no content and an attribute xsi:nil set to "true".

An element also has a sequence of namespace bindings, which are the set of in-scope namespaces for that element. Each namespace binding is a prefix, URI pair. Elements without namespace bindings are assumed to have an empty set of in-scope namespaces.

2.3.2 Examples of values

A well-formed document

  <fact>The cat weighs <weight units="lbs">12</weight> pounds.</fact>

In the absence of a Schema, this document is represented as

  element fact of type xdt:untyped {
    text { "The cat weighs " },
    element weight of type xdt:untyped {
      attribute units of type xdt:untypedAtomic {
        "lbs" of type xdt:untypedAtomic
      }
      text { "12" }
    },
    text { " pounds." }
  }

A document before and after validation.

  <weight xsi:type="xs:integer">42</weight>

The formal model for values can represent values before and after validation. Before validation, this element is represented as:

  element weight of type xdt:untyped {
    attribute xsi:type of type xdt:untypedAtomic {
      "xs:integer" of type xdt:untypedAtomic
    },
    text { "42" }
  }

After validation, this element is represented as:

  element weight of type xs:integer {
    attribute xsi:type of type xs:QName {
      "xs:integer" of type xs:QName
    },
    42 of type xs:integer
  }

An element with a list type

  <sizes>1 2 3</sizes>

Before validation, this element is represented as:

  element sizes of type xdt:untyped {
    text { "1 2 3" }
  }

Assume the following Schema.

  <xs:element name="sizes" type="sizesType"/>
  <xs:simpleType name="sizesType">
    <xs:list itemType="sizeType"/>
  </xs:simpleType>
  <xs:simpleType name="sizeType">
    <xs:restriction base="xs:integer"/>
  </xs:simpleType>

After validation against this Schema, the element is represented as:

  element sizes of type sizesType {
    1 of type sizeType,
    2 of type sizeType,
    3 of type sizeType
  }

An element with an anonymous type

  <sizes>1 2 3</sizes>

Before validation, this element is represented as:

  element sizes of type xdt:untyped {
    text { "1 2 3" }
  }

Assume the following Schema.

  <xs:element name="sizes">
    <xs:simpleType>
      <xs:list itemType="xs:integer"/>
    </xs:simpleType>
  </xs:element>

After validation, this element is represented as:

  element sizes of type fs:anon1 {
    1 of type xs:integer,
    2 of type xs:integer,
    3 of type xs:integer
  }

where fs:anon₁ stands for the internal anonymous name generated by the system for the sizes element.

A nillable element with xsi:type set to true:

  <sizes xsi:nil="true"/>

Before validation, this element is represented as:

  element sizes of type xdt:untyped {
    attribute xsi:nil of type xdt:untypedAtomic { "true" of type xdt:untypedAtomic }
  }

Assume the following Schema.

  <xs:element name="sizes" type="sizesType" nillable="true"/>

After validation against this Schema, the element is represented as:

  element sizes nilled of type sizesType {
    attribute xsi:nil of type xs:boolean { true of type xs:boolean }
  }

An element with a union type

  <sizes>1 two 3 four</sizes>

Before validation, this element is represented as:

  element sizes of type xdt:untyped {
    text { "1 two 3 four" }
  }

Assume the following Schema:

  <xs:element name="sizes" type="sizesType"/>
  <xs:simpleType name="sizesType">
    <xs:list itemType="sizeType"/>
  </xs:simpleType>
  <xs:simpleType name="sizeType">
    <xs:union memberType="xs:integer xs:string"/>
  </xs:simpleType>

After validation against this Schema, the element is represented as:

  element sizes of type sizesType {
    1 of type xs:integer,
    "two" of type xs:string,
    3 of type xs:integer,
    "four" of type xs:string
  }

2.4.1 XML Schema and the [XPath/XQuery] Type System

The [XPath/XQuery] type system is based on [Schema Part 1] and [Schema Part 2]. [Schema Part 1] and [Schema Part 2] specify normatively the type information available in [XPath/XQuery]. We define the formal notation that is used in this document to describe and manipulate types in inference rules. Formal types are used for specification purposes only and are not exposed to the [XPath/XQuery] user.

Representation of content models. For the purpose of static typing, the [XPath/XQuery] type system only describes minOccurs, maxOccurs, and minLength, maxLength on list types for the occurrences that correspond to the DTD operators +, *, and ?. Choices are represented using the DTD operator |. All groups are represented using the interleaving operator (&).

Representation of anonymous types. To clarify the semantics, the [XPath/XQuery] type system makes all anonymous types explicit.

Representation of XML Schema simple type facets and identity constraints. For simplicity, XML Schema simple type facets and identity constraints are not formally represented in the [XPath/XQuery] type system. However, an [XPath/XQuery] implementation supporting XML Schema import and validation must take simple type facets and identity constraints into account.

This document describe types in the [XPath/XQuery] types system, as well as the operations and properties over those types which are used to define the [XPath/XQuery] static typing feature. The two most important properties are whether a data instances matches a type, and whether a type is a subtype of another. Those properties are described in [8.3 Judgments for type matching]. This document does not describe all other possible properties over those types.

The mapping from XML Schema into the [XPath/XQuery] type system is given in [C Importing Schemas]. The rest of this section is organized as follows. [2.4.2 Item types] describes item types, [2.4.3 Content models] describes content models, and [2.4.4 Top level definitions] describe top-level type declarations.

2.4.2 Item types

An item type is either an atomic type, an element type, an attribute type, a document node type, a text node type, a comment node type, or a processing instruction type. We distinguish between document nodes, attribute nodes, and nodes that can occur in element content (elements, comments, processing instructions, and text nodes), as we need to refer to element content types later in the formal semantics.

Item Types

An element or attribute type has an optional name and an optional type reference. A name alone corresponds to a reference to a global element or attribute declaration. A name with a type reference corresponds to a local element or attribute declaration. The word "element" or "attribute" alone refers to the wildcard types for any element or any attribute. In addition, an element type has an optional nillable flag that indicates whether the element can be nilled or not.

A document type has an optional content type. If no content type is given, then the type is treated as being the wildcard type for documents, i.e., a sequence of text and element nodes. For consistency with element nodes, PIs and comments are not indicated in that wildcard type, but may occur in instances.

Note

Generic node types (e.g., node()) such as used in the SequenceType production, are interpreted in the type system as a union of the corresponding node types (e.g., element,attribute,text,comment and processing-instruction nodes) and therefore do not appear in the grammar. The semantics of sequence types is described in [3.5.4 SequenceType Matching].

Examples

The following is a text node type

  text

The following is a type for all elements

  element * of type xs:anyType

The following is a type for all elements of type string

  element * of type xs:string

The following is a type for a nillable element of type string and with name size

  element size nillable of type xs:string

The following is a reference to a global attribute declaration

  attribute sizes

The following is a type for elements with anonymous type fs:anon₁:

  element sizes of type fs:anon1

2.4.3 Content models

Following XML Schema, types in [XPath/XQuery] are composed from item types by optional, one or more, zero or more, all group, sequence, choice, empty sequence (written empty), or empty choice (written none).

The type empty matches the empty sequence. The type none matches no values. none is the identity for choice, that is (Type | none) = Type. The type none is the static type for [7.2.9 The fn:error function].

Types

The [XPath/XQuery] type system includes three binary operators on types: ",", "|" and "&", corresponding respectively to sequence, choice and all groups in Schema. The [XPath/XQuery] type system includes three unary operators on types: "*", "+", and "?", corresponding respectively to zero or more instances of the type, one or more instances of the type, or an optional instance of the type.

The "&" operator builds the "interleaved product" of two types. The type Type₁ & Type₂ matches any sequence that is an interleaving of two sequences of items, Value₁ and Value₂, with Value₁ matching Type₁ and Value₂ matching Type₂. The interleaving of two sequences of items Value₁ and Value₂ is any sequence Value₀ such that there is an ordered partition of Value₀ into the two sub-sequences Value₁ and Value₂. The interleaved product captures the semantics of all groups in XML Schema, but is more general as it applies to arbitrary types. All groups in XML Schema are restricted to apply only on global or local element declarations with minOccurs 0 or 1, and maxOccurs 1.

For example, consider the types Type₁ = xs:integer,xs:integer,xs:integer and Type₂ = xs:string,xs:string. Value₁ = (1,2,3) matches the type Type₁ and Value₂ = ("a","b") matches the type Type₂. Any of the following Value₀ are interleavings of Value₁ and Value₂, and therefore match the type (Type₁ & Type₂):

Value0 = (1,2,3,"a","b")
Value0 = (1,2,"a",3,"b")
Value0 = (1,2,"a","b",3)
Value0 = (1,"a",2,3,"b")
Value0 = (1,"a",2,"b",3)
Value0 = (1,"a","b",2,3)
Value0 = ("a",1,2,3,"b")
Value0 = ("a",1,2,"b",3)
Value0 = ("a",1,"b",2,3)
Value0 = ("a","b",1,2,3)

Types precedence order. To improve readability when writing types, we assume the following precedence order between operators on types.

Parenthesis can be used to enforce precedence. For instance

  xs:string | xs:integer, xs:float*

is equivalent to

  xs:string | (xs:integer, (xs:float*))

and a different precedence can be obtained by writing

  ((xs:string | xs:integer), xs:float)*

Examples

A sequence of elements

The "," operator builds the "sequence" of two types. For example,

  element title of type xs:string, element year of type xs:integer

is a sequence of an element title of type string followed by an element year of type integer.

The union of two element types

The "|" operator builds the "union" of two types. For example,

  element editor of type xs:string | element bib:author

means either an element editor of type string, or a reference to the global element bib:author.

An all group of two elements

The "&" operator builds the "interleaved product" of two types. For example,

  (element a & element b) =
    element a, element b
  | element b, element a

which specifies that the a and b elements can occur in any order.

An empty type

The following type matches the empty sequence.

  empty

A sequence of zero or more elements

The following type matches zero or more elements each of which can be a surgeon or a plumber.

  (element surgeon | element plumber)*

2.4.4 Top level definitions

Top level definitions correspond to global element declarations, global attribute declarations and type definitions in XML Schema.

Type Definitions

A type definition has a name (possibly anonymous) and a type derivation. In the case of a complex type, the derivation indicates whether it is derived by extension or restriction, its base type, and its content model, with an optional flag indicating if it has mixed content.

Example

For instance, the following complex type

 <complexType name="UKAddress">
   <complexContent>
     <extension base="ipo:Address">
       <sequence>
         <element name="postcode" type="ipo:UKPostcode"/>
       </sequence>
       <attribute name="exportCode" type="positiveInteger" fixed="1"/>
     </extension>
   </complexContent>
 </complexType>

is represented as follows

  define type UKAddress extends ipo:Address {
    attribute exportCode of type ipo:UKPostcode,
    element postcode of type positiveInteger
  };

Example

In the case of simple types derived by union or list, the derivation is always a restriction from the base type xs:anySimpleType, and has a content which is a union of the member types, or a repetition of the item type. For instance, the two following simple type declarations

<xsd:simpleType name="listOfMyIntType">
  <xsd:list itemType="myInteger"/>
</xsd:simpleType>

<xsd:simpleType name="zipUnion">
  <xsd:union memberTypes="USState FrenchRegion"/>
</xsd:simpleType>

are represented as follows

define type listOfMyIntType restricts xs:anySimpleType {
  myInteger*
}

define type zipUnion restricts xs:anySimpleType {
  USState | FrenchRegion
}

Example

In the case of an atomic type, it just indicates its base type. For instance, the following type definition

<xsd:simpleType name="SKU">
 <xsd:restriction base="xsd:string">
  <xsd:pattern value="\d{3}-[A-Z]{2}"/>
 </xsd:restriction>
</xsd:simpleType>

is represented as follow

  define type SKU restrict xsd:string;

Example

When the type derivation is omitted, the type derives by restriction from xs:anyType. For instance:

  define type Bib { element book* } =
  define type Bib restricts xs:anyType { element book* }

Example

Empty content can be indicated with the explicit empty sequence, or omitted, as in:

  define type Bib { } =
  define type Bib { empty }

Global element and attribute declarations always have a name and a reference to a (possibly anonymous) type. A global element declaration also may declare a substitution group for the element and whether the element is nillable.

Example

A type declaration with one element name of type xs:string follows by one or more elements street of type xs:string.

  define type Address {
    element name of type xs:string,
    element street of type xs:string*
  }

Example

A type declaration with complex content derived by extension

  define type USAddress extends Address {
    element zip name of type xs:integer
  }

Example

A type declaration with mixed content

  define type Section mixed {
    (element h1 of type xs:string |
     element p of type xs:string |
     element div of type Section)*
  }

Example

A type declaration with simple content derived by restriction

  define type SKU restricts xs:string

Example

An element declaration

  define element address of type Address

Example

An element declaration with a substitution group

  define element usaddress substitutes for address of type USAddress

Example

An element declaration which is nillable

  define element zip nillable of type xs:integer

2.4.5 Example of a complete Schema

Here is a schema describing purchase orders from [XML Schema Part 0].

  <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  
   <xsd:annotation>
    <xsd:documentation xml:lang="en">
     Purchase order schema for Example.com.
     Copyright 2000 Example.com. All rights reserved.
    </xsd:documentation>
   </xsd:annotation>
  
   <xsd:element name="purchaseOrder" type="PurchaseOrderType"/>
  
   <xsd:element name="comment" type="xsd:string"/>
  
   <xsd:complexType name="PurchaseOrderType">
    <xsd:sequence>
     <xsd:element name="shipTo" type="USAddress"/>
     <xsd:element name="billTo" type="USAddress"/>
     <xsd:element ref="comment" minOccurs="0"/>
     <xsd:element name="items"  type="Items"/>
    </xsd:sequence>
    <xsd:attribute name="orderDate" type="xsd:date"/>
   </xsd:complexType>
  
   <xsd:complexType name="USAddress">
    <xsd:sequence>
     <xsd:element name="name"   type="xsd:string"/>
     <xsd:element name="street" type="xsd:string"/>
     <xsd:element name="city"   type="xsd:string"/>
     <xsd:element name="state"  type="xsd:string"/>
     <xsd:element name="zip"    type="xsd:decimal"/>
    </xsd:sequence>
    <xsd:attribute name="country" type="xsd:NMTOKEN" fixed="US"/>
   </xsd:complexType>
  
   <xsd:complexType name="Items">
    <xsd:sequence>
     <xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
      <xsd:complexType>
        <xsd:sequence>
         <xsd:element name="productName" type="xsd:string"/>
         <xsd:element name="quantity">
          <xsd:simpleType>
           <xsd:restriction base="xsd:positiveInteger">
            <xsd:maxExclusive value="100"/>
           </xsd:restriction>
          </xsd:simpleType>
         </xsd:element>
         <xsd:element name="USPrice"  type="xsd:decimal"/>
         <xsd:element ref="comment"   minOccurs="0"/>
         <xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
        </xsd:sequence>
        <xsd:attribute name="partNum" type="SKU" use="required"/>
      </xsd:complexType>
     </xsd:element>
    </xsd:sequence>
   </xsd:complexType>
  
   <!-- Stock Keeping Unit, a code for identifying products -->
   <xsd:simpleType name="SKU">
    <xsd:restriction base="xsd:string">
     <xsd:pattern value="\d{3}-[A-Z]{2}"/>
    </xsd:restriction>
   </xsd:simpleType>
  
  </xsd:schema>

Here is the mapping of the above schema into the [XPath/XQuery] type system.

  declare namespace xsd = "http://www.w3.org/2001/XMLSchema";

  define element purchaseOrder of type PurchaseOrderType;
 
  define element comment of type xsd:string;
  
  define type PurchaseOrderType {
    attribute orderDate of type xsd:date?,
    element shipTo of type USAddress,
    element billTo of type USAddress,
    element comment?,
    element items of type Items
  };

  define type USAddress {
    attribute country of type xsd:NMTOKEN,
    element name of type xsd:string,
    element street of type xsd:string,
    element city of type xsd:string,
    element state of type xsd:string,
    element zip of type xsd:decimal
  };

  define type Items {
    attribute partNum of type SKU,
    element item of type fs:anon1*
  };

  define type fs:anon1 {
    element productName of type xsd:string,
    element quantity of type fs:anon2,
    element USPrice of type xsd:decimal,
    element comment?,
    element shipDate of type xsd:date?
  };

  define type fs:anon2 restricts xsd:positiveInteger;

  define type SKU restrict xsd:string;

Note that the two anonymous types in the item element declarations are mapping to types with names fs:anon₁ and fs:anon₂.

The following additional definitions illustrate how more advanced XML Schema features (a complex type derived by extension, an anonymous simple type derived by restriction, and substitution groups) are represented in the [XPath/XQuery] type system.

  <complexType name="NYCAddress">
    <complexContent>
     <extension base="USAddress">
      <sequence>
       <element ref="apt"/>
      </sequence>
     </extension>
    </complexContent>
  </complexType>

  <element name="apt">
    <xsd:simpleType>
     <xsd:restriction base="xsd:positiveInteger">
      <xsd:maxExclusive value="10000"/>
     </xsd:restriction>
    </xsd:simpleType>
  </element>

  <element name="usaddress" substitutionGroup="address" type="USAddress"/>
  <element name="nycaddress" substitutionGroup="usaddress" type="NYCAddress"/>

The above definitions are mapped into the [XPath/XQuery] type system as follows:

  define type NYCAddress extends USAddress {
    element apt
  }

  define element apt of type fs:anon3

  define type fs:anon3 restricts xsd:positiveInteger

  define element usaddress  substitutes for address of type USAddress
  define element nycaddress substitutes for usaddress of type NYCAddress

3.1.1 Static Context

Notation

We introduce the following auxiliary grammar production to describe function signatures.

statEnv denotes the environment available during static analysis. Static analysis may extend parts of the static environment. The static environment is also available during dynamic evaluation.

If analysis of an expression relies on some component of the static context that has not been assigned a value, a static error is raised.

The following environment components are part of the static environment:

Note that the boundary-space behavior is not formally specified in this document.

Environments have an initial state when [expression/query] processing begins, containing, for example, the function signatures of all built-in functions. The initial values for the static context are defined in Section C Context Components^XQ and Section C Context Components^XP and is denoted by statEnvDefault in the Formal Semantics.

Here is an example that shows how the static environment is modified in response to a namespace definition.

This rule reads as follows: "the phrase on the bottom (a namespace declaration in the query prolog followed by a sequence of expressions) is well-typed (accepted by the static type inference rules) within an environment statEnv if the sequence of expressions above the line is well-typed in the environment obtained from statEnv by adding the namespace declaration".

The helper function fs:active_ns(statEnv) returns all the active in-scope namespaces in the given static environment.

For each attribute and element node in Value, such that the node has name expanded-QName in the namespace URI, the helper function fs:get_static_ns_from_items(statEnv, Value) returns the in-scope namespace that corresponds to URI. This is a reverse-lookup on statEnv.namespace by URI.

3.1.2 Dynamic Context

dynEnv denotes the environment available during dynamic evaluation. Dynamic evaluation may extend parts of the dynamic environment.

If evaluation of an expression relies on some component of the dynamic context that has not been assigned a value, a dynamic error is raised.

The following environment components are part of the dynamic environment:

The initial values for the dynamic context are defined in Section C Context Components^XQ and Section C Context Components^XP. The corresponding initial dynamic environment is denoted by dynEnvDefault in the Formal Semantics.

The following Formal Semantics variables represent the context item, context position, and context size properties of the dynamic context:

Within this document, variables with the "fs" prefix are reserved for use in the formal specification. Values of $fs:position and $fs:last can be obtained by invoking the fn:position and fn:last functions, respectively.

3.2.1 Processing model

The following figure depicts the [XPath/XQuery] processing model

Figure 1: Processing Model Overview

This processing model is not intended to describe an actual implementation, although a naive implementation might be based upon it. It does not prescribe an implementation technique, but any implementation should produce the same results as obtained by following this processing model and applying the rest of the Formal Semantics specification.

Query processing consists of two phases: a static analysis phase and a dynamic evaluation phase. Static analysis is further divided into four sub-phases. Each phase consumes the result of the previous phase and generates output for the next phase. For each processing phase, we point to the relevant notations introduced later in the document.

[Definition: The static analysis phase depends on the expression itself and on the static context. The static analysis phase does not depend on input data (other than schemas).]

The purpose of the static analysis phase is to detect errors, e.g., syntax errors or type errors, at compile time rather than at run-time. If no error occurs, the result of static analysis could be some compiled form of [expression/query], suitable for execution by a compiled-[expression/query] processor. Static analysis consists of the following sub-phases:

1. Parsing. (Step SQ1 in Figure 1). The grammar for the [XPath/XQuery] syntax is defined in [XQuery 1.0: An XML Query Language]. Parsing may generate syntax errors. If no error occurs, an internal operation tree of the parsed query is created.

2. Static Context Processing. (Steps SQ2, SQ3, and SQ4 in Figure 1). The static semantics of [expression/query] depends on the input static context. The input static context needs to be generated before the [expression/query] can be analysed. In XQuery, the input static context may be defined by the processing environment and by declarations in the Query Prolog (See [5 Modules and Prologs]). In XPath, the input static context is defined by the processing environment. The static context is denoted by statEnv.

3. Normalization. (Step SQ5 in Figure 1). To simplify the semantics specification, some normalization is performed on the [expression/query]. The [XPath/XQuery] language provides many powerful features that make [expression/query]s simpler to write and use, but are also redundant. For instance, a complex for expression might be rewritten as a composition of several simple for expressions. The language composed of these simpler [expression/query] is called the [XPath/XQuery] Core language and is described by a grammar which is a subset of the XQuery grammar. The grammar of the [XPath/XQuery] Core language is given in [A Normalized core grammar].

   During the normalization phase, each [XPath/XQuery] [expression/query] is mapped into its equivalent [expression/query] in the Core. (Note that this has nothing to do with Unicode Normalization, which works on character strings.) Normalization works by recursive application of the normalization rules over a given expression.

   Specifically the normalization phase is defined in terms of the static part of the context (statEnv) and a [expression/query] (Expr) abstract syntax tree. Formal notations for the normalization phase are introduced in [3.2.2 Normalization judgment].

   After normalization, the full semantics is obtained by giving a semantics to the normalized Core [expression/query]. This is done during the last two phases.

4. Static type analysis. (Step SQ6 in Figure 1). Static type analysis is optional. If this phase is not supported, then normalization is followed directly by dynamic evaluation.

   Static type analysis checks whether each [expression/query] is type safe, and if so, determines its static type. Static type analysis is defined only for Core [expression/query]. Static type analysis works by recursive application of the type inference rules over a given expression.

   If the [expression/query] is not type-safe, static type analysis yields a type error. For instance, a comparison between an integer value and a string value might be detected as an type error during the static type analysis. If static type analysis succeeds, it yields an abstract syntax tree where each sub-expression is associated with its static type.

   More precisely, the static analysis phase is defined in terms of the static context (statEnv) and a Core [expression/query] (CoreExpr). Formal notations for the static analysis phase are introduced in [3.2.3 Static typing judgment].

   Static typing does not imply that the content of XML documents must be rigidly fixed or even known in advance. The [XPath/XQuery] type system accommodates "flexible" types, such as elements that can contain any content. Schema-less documents are handled in [XPath/XQuery] by associating a standard type with the document, such that it may include any legal XML content.

If the static analysis phase succeeds, the dynamic evaluation phase (sometimes also called "execution") evaluates a query on input document(s).

1. Dynamic Context Processing. (Steps DQ2 and DQ3 in Figure 1).The dynamic semantics of [expression/query] depends on the dynamic input context. The dynamic input context needs to be generated before the [expression/query] can be evaluated. The dynamic input context may be defined by the processing environment and by statements in the Query Prolog (See [5 Modules and Prologs]). In XPath, the dynamic input context is defined by the processing environment. The static input context is denoted by dynEnv.

2. Dynamic Evaluation. (Steps DQ4 and DQ5 in Figure 1). This phase computes the value of an [expression/query]. The semantics of evaluation is defined only for Core [expression/query] terms. The formal description of evaluation works by recursive application of the evaluation rules over a given expression. (Note that in practice some implementations may prefer top-down evaluation strategies.) Evaluation may result in a value OR a dynamic error, which may be a non-type error or a type error. If static typing of an expression does not raise a type error, then dynamic evaluation of the same expression will not raise a type error (and thus dynamic type checking can be avoided when static typing is enabled). Dynamic evaluation may still raise a non-type error.

   The dynamic evaluation phase is defined in terms of the static context (statEnv) and evaluation context (dynEnv), and a Core [expression/query] (CoreExpr). Formal notations for the dynamic evaluation phase are introduced in [3.2.4 Dynamic evaluation judgment].

Static type analysis catches only certain classes of errors. For instance, it can detect a comparison operation applied between incompatible types (e.g., xs:int and xs:date). Some other classes of errors cannot be detected by the static analysis and are only detected at evaluation time. For instance, whether an arithmetic expression on 32 bit integers (xs:int) yields an out-of-bound value can only be detected at run-time by looking at the data.

While implementations are free to implement different processing models, the [XPath/XQuery] static semantics relies on the existence of a static type analysis phase that precedes any access to the input data.

The above processing phases are all internal to the [XPath/XQuery] processor. They do not deal with how the [XPath/XQuery] processor interacts with the outside world, notably how it accesses actual documents and types. A typical [expression/query] engine would support at least three other important processing phases:

1. Schema Import Processing. The [XPath/XQuery] type system is based on XML Schema. In order to perform dynamic or static typing, the [XPath/XQuery] processor needs to build type descriptions that correspond to the schema(s) of the input documents. This phase is achieved by mapping all schemas required by the [expression/query] into the [XPath/XQuery] type system. The XML Schema import phase is described in [C Importing Schemas].

2. Data Model Generation. Expressions are evaluated on values in the [Data Model]. XML documents must be loaded into the [Data Model] before the evaluation phase. This is described in the [Data Model] and is not discussed further here.

3. Serialization. Once the [expression/query] is evaluated, processors might want to serialize the result of the [expression/query] as actual XML documents. Serialization of data model instances is described in [Data Model Serialization] and is not discussed further here.

The parsing phase is not specified formally; the formal semantics does not define a formal model for the syntax trees, but uses the [XPath/XQuery] concrete syntax directly. More details about parsing for XQuery 1.0 can be found in the [XQuery 1.0: An XML Query Language] document and more details about parsing for XPath 2.0 can be found in the [XML Path Language (XPath) 2.0] document. No further discussion of parsing is included here.

3.2.2 Normalization judgment

Normalization is specified using mapping rules, which describe how a [XPath/XQuery] expression is rewritten into an expression in the [XPath/XQuery] Core. Mapping rules are also used in [C Importing Schemas] to specify how XML Schemas are imported into the [XPath/XQuery] type system.

Notation

Mapping rules are written using a square bracket notation, as follows:

The original "object" is written above the == sign. The rewritten "object" is written beneath the == sign. The subscript is used to indicate what kind of "object" is mapped, and sometimes to pass some information between mapping rules.

Since normalization is always applied in the presence of a static context, the above rule is a shorthand for:

The static environment is used in certain normalization rules (e.g. for normalization of function calls). To keep the notation simpler, the static environment is not written in the normalization rules, but it is assumed to be available.

The normalization rule that is used to map "top-level" expressions in the [XPath/XQuery] syntax into expressions in the [XPath/XQuery] Core is:

which indicates that the expression Expr is normalized to the expression CoreExpr in the [XPath/XQuery] Core (with the implied statEnv).

Example

For instance, the following [expression/query]

    for $i in (1, 2),
        $j in (3, 4)
    return
      element pair { ($i,$j) }

is normalized to the Core expression

    for $i in (1, 2) return
      for $j in (3, 4) return
          element pair { ($i,$j) }

in which the "FWLR" expression is mapped into a composition of two simpler "for" expressions.

3.2.3 Static typing judgment

The static semantics is specified using type inference rules, which relate [XPath/XQuery] expressions to types and specify under what conditions an expression is well typed.

Notation

The judgment

holds when, in the static environment statEnv, the expression Expr has type Type.

Example

The result of static type inference is to associate a static type with every [expression/query], such that any evaluation of that [expression/query] is guaranteed to yield a value that belongs to that type.

For instance, the following expression.

   let $v := 3 return $v+5

has type xs:integer. This can be inferred as follows: the input literals '3' and '5' have type integer, so the variable $v also has type integer. Since the sum of two integers is an integer, the complete expression has type integer.

Note

The type of an expression is computed by inference. Static type inference rules define for each kind of expression how to compute the type of the expression given the types of its sub-expressions. Here is a simple example:

This rule states that if the conditional expression of an "if" expression has type boolean, then the type of the entire expression is one of the two types of its "then" and "else" clauses. Note that the resulting type is represented as a union: '(Type₂|Type₃)'.

The "left half" (the part before the :) of the expression below the line corresponds to some [expression/query], for which a type is computed. If the [expression/query] has been parsed into an internal abstract syntax tree, this usually corresponds to some node in that tree. The expression usually has patterns in it (here Expr₁, Expr₂, and Expr₃) that need to be matched against the children of the node in the abstract syntax tree. The expressions above the line indicate things that need to be computed to use this rule; in this case, the types of the condition expression and the two branches of the if-then-else expression. Once those types are computed (by further applying static inference rules recursively to the expressions on each side), then the type of the expression below the line can be computed. This example illustrates a general feature of the [XPath/XQuery] type system: the type of an expression depends only on the type of its sub-expressions. The overall static type inference algorithm is recursive, following the abstract syntax of the [expression/query]. At each point in the recursion, an appropriate matching inference rule is sought; if at any point there is no applicable rule, then static type inference has failed and the [expression/query] is not type correct.

3.2.4 Dynamic evaluation judgment

The dynamic, or operational, semantics is specified using value inference rules, which relate [XPath/XQuery] expressions to values, and in some cases specify the order in which an [XPath/XQuery] expression is evaluated.

Notation

The judgment

holds when, in the static environment statEnv and dynamic environment dynEnv, the expression Expr yields the value Value.

The static environment is used in certain cases (e.g. for type matching) during evaluation. To keep the notation simpler, the static environment is not written in the dynamic inference rules, but it is assumed to be available.

Example

For instance, the following expression.

   let $v := 3 return $v+5

yields the integer value 8. This can be inferred as follows: the input literals '3' and '5' denote the values 3 and 5, respectively, so the variable $v has the value 3. Since the sum of 3 and 5 is 8, the complete expression has the value 8.

Note

As with static type inference, logical inference rules are used to determine the value of each expression, given the dynamic environment and the values of its sub-expressions.

The inference rules used for dynamic evaluation, like those for static type inference, follow a bottom-up recursive structure, computing the value of expressions from the values of their sub-expressions.

3.4.1 Document Order

Document order is defined in [Data Model].

3.4.2 Atomization

Atomization converts an item sequence into a sequence of atomic values and is implemented by the fn:data function. Atomization is applied to a value when the value is used in a context in which a sequence of atomic values is required.

3.4.3 Effective Boolean Value

If a sequence of items is encountered where a boolean value is expected, the item sequence's effective boolean value is used. The fn:boolean function returns the effective boolean value of an item sequence.

3.4.4 Input Sources

[XPath/XQuery] has a set of functions that provide access to input data. These functions are of particular importance because they provide a way in which an expression can reference a document or a collection of documents. The dynamic semantics of these three input functions are described in more detail in [Functions and Operators].

3.4.5 URI Literals

In certain places in the XQuery grammar, a statically known valid absolute URI is required. These places are denoted by the grammatical symbol URILiteral, and are treated as described in [XQuery 1.0: An XML Query Language].

3.5.1 Predefined Schema Types

All the built-in types of XML Schema are recognized by [XPath/XQuery]. In addition, [XPath/XQuery] recognizes the predefined types xdt:anyAtomicType, xdt:untypedAtomic and xdt:untyped and the duration subtypes xdt:yearMonthDuration and xdt:dayTimeDuration . The definition of those types in the [XPath/XQuery] type system is given below.

[Definition: The following type definition of xs:anyType reflects the semantics of the Ur type from Schema in the [XPath/XQuery] type system.]

  define type xs:anyType restricts xs:anyType {
    attribute * of type xs:anySimpleType*,
    ( xdt:anyAtomicType* | ( element * of type xs:anyType | text | comment | processing-instruction )* )
  }

[Definition: The following type definition of xs:anySimpleType reflects the semantics of the Ur simple type from Schema in the [XPath/XQuery] type system.]

  define type xs:anySimpleType restricts xs:anyType {
    xdt:anyAtomicType*
  }

The name of the Ur simple type is xs:anySimpleType. It is derived by restriction from xs:anyType, its content is a sequence any atomic types.

[Definition: The following type definition of xdt:anyAtomicType reflects the semantics of xdt:anyAtomicType in the [XPath/XQuery] type system.]

  define type xdt:anyAtomicType restricts xs:anySimpleType {
    ( xs:string
    | xs:boolean
    | xs:decimal
    | xs:float
    | xs:double
    | xs:duration
    | xs:dateTime
    | xs:time
    | xs:date
    | xs:gYearMonth
    | xs:gYear
    | xs:gMonthDay
    | xs:gDay
    | xs:gMonth
    | xs:hexBinary
    | xs:base64Binary
    | xs:anyURI
    | xs:QName
    | xs:NOTATION
    | xdt:untypedAtomic )
  }

[Definition: The following type definitions of the XML Schema primitive types reflect the semantics of the primitive types from Schema in the [XPath/XQuery] type system.]

  define type xs:string       restricts xdt:anyAtomicType
  define type xs:boolean      restricts xdt:anyAtomicType
  define type xs:decimal      restricts xdt:anyAtomicType
  define type xs:float        restricts xdt:anyAtomicType
  define type xs:double       restricts xdt:anyAtomicType
  define type xs:duration     restricts xdt:anyAtomicType
  define type xs:dateTime     restricts xdt:anyAtomicType
  define type xs:time         restricts xdt:anyAtomicType
  define type xs:date         restricts xdt:anyAtomicType
  define type xs:gYearMonth   restricts xdt:anyAtomicType
  define type xs:gYear        restricts xdt:anyAtomicType
  define type xs:gMonthDay    restricts xdt:anyAtomicType
  define type xs:gDay         restricts xdt:anyAtomicType
  define type xs:gMonth       restricts xdt:anyAtomicType
  define type xs:hexBinary    restricts xdt:anyAtomicType
  define type xs:base64Binary restricts xdt:anyAtomicType
  define type xs:anyURI       restricts xdt:anyAtomicType
  define type xs:QName        restricts xdt:anyAtomicType
  define type xs:NOTATION     restricts xdt:anyAtomicType

All of those primitive types derive from xdt:anyAtomicType. Note that the value space of each atomic type (such as xs:string) does not appear. The value space for each type is built-in and is as defined in [Schema Part 2].

[Definition: The type xdt:untypedAtomic is defined as follows.]

  define type xdt:untypedAtomic restricts xdt:anyAtomicType

Note that this rule does not indicate the value space of xdt:untypedAtomic. By definition, xdt:untypedAtomic has the same value space as xs:string.

The following example shows two atomic values. The first one is a value of type string containing "Database". The second one is an untyped atomic value containing "Database".

  "Databases" of type xs:string
  "Databases" of type xdt:untypedAtomic

[Definition: The type xdt:untyped is defined as follows.]

  define type xdt:untyped restricts xs:anyType {
    attribute * of type xdt:untypedAtomic*,
    ( element * of type xdt:untyped | text | comment | processing-instruction )*
  }

[Definition: The following type definitions of the XML Schema derived types reflect the semantics of the XML Schema types derived by restriction from another atomic type.]

  define type xs:normalizedString   restricts xs:string
  define type xs:token              restricts xs:normalizedString
  define type xs:language           restricts xs:token
  define type xs:NMTOKEN            restricts xs:token
  define type xs:Name               restricts xs:token
  define type xs:NCName             restricts xs:Name
  define type xs:ID                 restricts xs:Name
  define type xs:IDREF              restricts xs:Name
  define type xs:ENTITY             restricts xs:Name
  define type xs:integer            restricts xs:decimal
  define type xs:nonPositiveInteger restricts xs:integer
  define type xs:negativeInteger    restricts xs:nonPositiveInteger
  define type xs:long               restricts xs:integer
  define type xs:int                restricts xs:long
  define type xs:short              restricts xs:int
  define type xs:byte               restricts xs:short
  define type xs:nonNegativeInteger restricts xs:integer
  define type xs:unsignedLong       restricts xs:nonNegativeInteger
  define type xs:unsignedInt        restricts xs:unsignedLong
  define type xs:unsignedShort      restricts xs:unsignedInt
  define type xs:unsignedByte       restricts xs:unsignedShort
  define type xs:positiveInteger    restricts xs:nonNegativeInteger

Three XML Schema built-in derived types are derived by list, as follows. Note that those derive directly from xs:anySimpleType, since they are derived by list, and that their value space is defined using a "one or more" occurrence indicator.

  define type xs:NMTOKENS restricts xs:anySimpleType { xs:NMTOKEN+ }
  define type xs:IDREFS   restricts xs:anySimpleType { xs:IDREF+ }
  define type xs:ENTITIES restricts xs:anySimpleType { xs:ENTITY+ }

For example, here is an element whose content is of type xs:IDREFS.

  element a of type xs:IDREFS {
    "id1" of type xs:IDREF,
    "id2" of type xs:IDREF,
    "id3" of type xs:IDREF
  }

Note that the type name xs:IDREFS derives from xs:anySimpleType, but not from xs:IDREF. As a consequence, calling the following three XQuery functions with the element a as a parameter succeeds for f1 and f2, but raises a type error for f3.

  declare function f1($x as element(*,xs:anySimpleType)) { $x }
  declare function f2($x as element(*,xs:IDREFS)) { $x }
  declare function f3($x as element(*,xs:IDREF)) { $x }

[Definition: The totally ordered duration types, xdt:yearMonthDuration and xdt:dayTimeDuration , are derived by restriction from xs:duration.]

  define type xdt:yearMonthDuration restricts xs:duration
  define type xdt:dayTimeDuration   restricts xs:duration

[Definition: In addition, the Formal Semantics uses the additional type fs:numeric. This type is necessary for the specification of some of XPath type conversion rules. It is defined as follows.]

  define type fs:numeric restricts xdt:anyAtomicType { xs:decimal | xs:float | xs:double }

3.5.2 Typed Value and String Value

The typed value of a node is computed by the fn:data function, and the string value of a node is computed by the fn:string function, defined in [Functions and Operators]. The normative definitions of typed value and string value are defined in [Data Model].

3.5.3 SequenceType Syntax

Introduction

Sequence types can be used in [XPath/XQuery] to refer to an XML Schema type. Sequence types are used to declare the types of function parameters and in several [XPath/XQuery] expressions.

The syntax of sequence types is described by the following grammar productions.

SequenceType

Core Grammar

The Core grammar productions for sequence types are:

The semantics of SequenceTypes is defined by means of normalization rules from SequenceTypes into types in the [XPath/XQuery] type system (See [2.4 The [XPath/XQuery] Type System]).

However, the [XPath/XQuery] type system not being part of the [XPath/XQuery] syntax, the SequenceType syntax is still part of the [XPath/XQuery] Core. Normalization from SequenceTypes to types is not applied during the normalization phase but whenever a dynamic or static rule requires it. Normalization of SequenceTypes is the only example of normalization that does not yield an expression in the [XPath/XQuery] Core and that occurs on-demand in dynamic or static rules.

3.5.4 SequenceType Matching

Introduction

During processing of a query, it is sometimes necessary to determine whether a given value matches a type that was declared using the SequenceType syntax. This process is known as SequenceType matching, and is formally specified in [8.3 Judgments for type matching].

Notation

To define normalization of SequenceTypes to the [XPath/XQuery] type system, the following auxiliary mapping rule is used.

specifies that SequenceType is mapped to a Type, in the [XPath/XQuery] type system.

Normalization

OccurenceIndicators are left unchanged when normalizing SequenceTypes into [XPath/XQuery] types. Each kind of SequenceType component is normalized separately into the [XPath/XQuery] type system.

The "empty-sequence()" sequence type is mapped to the empty type.

An atomic type is normalized to itself in the [XPath/XQuery] type system.

An "element" SequenceType without content or with a wildcard and no type name is normalized into a wildcard element type.

An "element" SequenceType with a wildcard and a type name is normalized into a wildcard element type with a corresponding type name. The presence of a "?" after the type name indicates a nillable element.

An "element" SequenceType with a name and a type name is normalized into an element type with a corresponding type name. The presence of a "?" after the type name indicates a nillable element.

An "element" SequenceType with only a name is normalized into a nillable element type with a corresponding name. The reason for the normalization to allow nillable elements is because the semantics of SequenceTypes in that case allows it to match every possible element with that names, regardless of its type or nilled property.

A "schema-element" SequenceType with an element declaration is normalized into a reference to the corresponding global element declaration.

An "attribute" SequenceType without content or with a wildcard and no type name is normalized into a wildcard attribute type.

An "attribute" SequenceType with a wildcard and a type name is normalized into a wildcard attribute type with a corresponding type name.

An "attribute" SequenceType with a name and a type name is normalized into an attribute type with a corresponding type name.

A "schema-attribute" SequenceType with an attribute declaration is normalized into a reference to the corresponding global attribute declaration.

A "document-node()" sequence types is normalized into the corresponding document type.

A "document-node" sequence type with an element test (resp. a schema element test) is normalized into the corresponding document type, whose content is the normalization of the element test (resp. schema element test), interleaved with an arbitrary sequence of processing instruction, comment, and text nodes.

A "processing-instruction()" SequenceType is normalized into the corresponding processing-instruction type.

The [XPath/XQuery] type system does not model the target of a processing-instruction, which is treated as a dynamic property. Therefore a "processing-instruction" SequenceType with a string or NCName parameter is normalized into an optional processing-instruction type.

A "comment()" SequenceType is normalized into the corresponding comment type.

A "text()" SequenceType is normalized into the corresponding text type.

The "node()" SequenceType denotes any node. It is normalized into a choice between the corresponding wildcard types for each kind of node.

The "item()" SequenceType denotes any node or atomic value. It is normalized into a choice between the corresponding wildcard types for each kind of nodes or atomic values.

4.1.1 Literals

Introduction

A literal is a direct syntactic representation of an atomic value. [XPath/XQuery] supports two kinds of literals: string literals and numeric literals.

Literals

Core Grammar

The Core grammar productions for literals are:

Literals

Notation

To define the dynamic semantics of literals, we introduce the following auxiliary judgments.

The judgment

Holds if the literal expression LiteralExpr corresponds to the value AtomicValue. This judgment yields an atomic value, according to the rules described in [XQuery 1.0: An XML Query Language]. Notably, this judgment deals with handling of literal overflows for numeric literals, and handling of character references, and predefined entity references for string literals.

Normalization

Literals are left unchanged through normalization.

Static Type Analysis

In the static semantics, the type of an integer literal is simply xs:integer:

Dynamic Evaluation

In the dynamic semantics, an integer literal is evaluated by constructing an atomic value in the data model, which consists of the literal value and its type:

The formal definitions of decimal, double, and string literals are analogous to those for integer.

Static Type Analysis

Dynamic Evaluation

Static Type Analysis

Dynamic Evaluation

Static Type Analysis

Dynamic Evaluation

4.1.2 Variable References

Introduction

A variable evaluates to the value to which the variable's QName is bound in the dynamic context.

Variable References

Core Grammar

The Core grammar productions for variable references are:

Primary Expressions

Normalization

Variable references are left unchanged through normalization.

Static Type Analysis

In the static semantics, the type of a variable is simply its type in the static environment statEnv.varType:

If the variable is not bound in the static environment, a static type error is raised.

Dynamic Evaluation

In the dynamic semantics, a locally declared variable is evaluated by "looking up" its value in dynEnv.varValue:

In the dynamic semantics, a reference to a variable imported from a module is evaluated by accessing the dynamic context of the module in which the variable is declared.

4.1.3 Parenthesized Expressions

Core Grammar

The Core grammar production for parenthesized expressions is:

Empty parenthesis () always have the empty type. Remember that it is a static type error for most expressions other than () to have the empty type (see [4 Expressions] for the complete rule.)

Static Type Analysis

Dynamic Evaluation

Empty parenthesis () evaluate to the empty sequence.

4.1.4 Context Item Expression

Introduction

A context item expression evaluates to the context item, which may be either a node or an atomic value.

Normalization

A context item expression is normalized to the built-in variable $fs:dot. Because it can only be bound through the external context or a path expression, there is no need for a specific typing rule to enforce that its value is a singleton item.

4.1.5 Function Calls

Introduction

A function call consists of a QName followed by a parenthesized list of zero or more expressions. In [XPath/XQuery], the actual argument to a function is called an argument and the formal argument of a function is called a parameter. We use the same terminology here.

Function Calls

Because [XPath/XQuery] implicitly converts the values of function arguments, a normalization step is required.

Core Grammar

The Core grammar production for function calls is:

Function Calls

Notation

Normalization of function calls uses an auxiliary mapping []_{FunctionArgument(SequenceType)} used to insert conversions of function arguments that depend only on the expected SequenceType of the corresponding parameters. It is defined as follows:

where

• [Expr]_{AtomizeAtomic(SequenceType)} denotes

  fn:data(Expr)		If [SequenceType]sequencetype <: xdt:anyAtomicType*
  Expr		Otherwise

  which specifies that if the function expects atomic parameters, then fn:data is called to obtain them.

• [Expr]_{Convert(SequenceType)} denotes

  fs:convert-simple-operand(Expr,PrototypicalValue)	If [SequenceType]sequencetype <: xdt:anyAtomicType*
  Expr	Otherwise

  where PrototypicalValue is a built-in atomic value used to encode the expected atomic type (for instance the value 1.0 if the expected type is xs:decimal). A value is used here since [XPath/XQuery] expressions cannot operate directly on types. Which value is chosen does not have any impact on the actual semantics, only its actual atomic type matters.

Note

The fs:convert-simple-operand function takes a PrototypicalValue, which is a value of the target type, to ensure that conversion to base types is possible even though types are not first class objects in [XPath/XQuery].

Normalization

Each argument expression in a function call is normalized to its corresponding Core expression by applying []_{FunctionArgument(SequenceType)} for each argument with the expected SequenceType for the argument inserted.

Note that this normalization rule depends on the function signatures, which is used to get the types of the function parameters (SequenceType₁,...,SequenceType_n). For user-defined functions, the function signature can be obtained from the XQuery prolog where the function is declared. For built-in functions, the signature is given in the [Functions and Operators] document. For overloaded built-in functions, several signatures may exists, however, because they all correspond to sequences of atomic values, they all result in the same normalization.

Static Type Analysis

Different sets of static typing rules are used to type check function calls depending on which of the following categories the belong to: overloaded internal functions, built-in functions with a specific typing rule, and other built-in and user-defined functions.

The following rule is common to all those categories, and is used to bootstrap type inference, by first looking-up the expanded QName for the function, then applying the appropriate set of inference rule depending on the category in which the function is.

The following depends on the kind of function call.

1. If the expanded QName for the function corresponds to one of the overloaded internal fs: functions listed in [B.2 Mapping of Overloaded Internal Functions], the rules in [B.2 Mapping of Overloaded Internal Functions] are applied.

2. If the expanded QName for the function corresponds to one of the built-in functions with a specialized typing rule, listed in [7 Additional Semantics of Functions], the rules in [7 Additional Semantics of Functions] are applied.

3. Otherwise, the following general rule is applied.

The rule looks up the function in the static environment and checks that some signature for the function satisfies the following constraint: the type of each actual argument is a subtype of some type that can be promoted to the type of the corresponding function parameter. In this case, the function call is well typed and the result type is the return type specified in the function's signature.

The function body itself is not analyzed for each invocation: static typing of the function definition itself guarantees that the function body always returns a value of the declared return type.

Notice that the static context contains at most one function declaration for each function. This is possible since the treatment of overloaded operators is done through a set of specific rules which do not require access to the environment. See [B.2 Mapping of Overloaded Internal Functions].

Notation

The following auxiliary judgment

holds when applying the function with expanded QName expanded-QName, and parameters of type (Type₁,...,Type_n) on the values (Value₁,...,Value_n) yields the value Value.

That judgment is defined below for each kind of function (user-defined, built-in, external, and imported functions).

Dynamic Evaluation

The following rule applies to all the different kinds of functions using the previously defined judgment.

First the function name is expanded, and the expanded name is used to retrieve the function signature from the static environment. Then, the rule evaluates each function argument expression, and the resulting values are promoted according to the expected type for the function. The result of evaluating the function is obtained through the auxiliary judgment previously defined, and the resulting value is promoted according to the expected return type.

In case the function is a user defined function in a main module, the expression body is retrieved from the dynamic environment and used to compute the value of the function. The rule extends dynEnv.varValue by binding each formal variable to its corresponding value, and evaluates the body of the function in the new environment. The resulting value is the value of the function call.

Note that the function body is evaluated in the dynamic environment containing the main module declarations.

The rule for evaluating an function imported from a module is similar to that for evaluating a user-defined function in a main module, except that the function call is evaluated in the dynamic context of the module in which it is declared, and that the appropriate additional type matching must be performed.

If the function is a built-in function (resp. special formal semantics function), the value returned by the function is the one specified in [Functions and Operators] (resp. [7 Additional Semantics of Functions]).

If the function is an external function, the value returned by the function is implementation-defined.