XQuery 1.0 and XPath 2.0 Formal Semantics

W3C Recommendation 23 January 2007

This version:

http://www.w3.org/TR/2007/REC-xquery-semantics-20070123/

Latest version:

http://www.w3.org/TR/xquery-semantics/

Previous version:

http://www.w3.org/TR/2006/PR-xquery-semantics-20061121/

Editors:

Denise Draper, Microsoft <denised@microsoft.com>

Peter Fankhauser (XML Query WG), Infonyte GmbH <fankhaus@infonyte.com>

Mary Fernández (XML Query WG), AT&T Labs - Research <mff@research.att.com>

Ashok Malhotra (XML Query and XSL WGs), Oracle Corporation <ashok.malhotra@oracle.com>

Kristoffer Rose (XSL WG), IBM T.J. Watson Research Center <krisrose@us.ibm.com>

Michael Rys (XML Query WG), Microsoft <mrys@microsoft.com>

Jérôme Siméon (XML Query WG), IBM T.J. Watson Research Center <simeon@us.ibm.com>

Philip Wadler (XML Query WG), University of Edinburgh <wadler@inf.ed.ac.uk>

Please refer to the errata for this document, which may include some normative corrections.

See also translations.

This document is also available in these non-normative formats: XML and Recent revisions.

Copyright © 2007  W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

1 Introduction

This document defines the formal semantics of XQuery 1.0 and XPath 2.0. The present document is part of a set of documents that together define the XQuery 1.0 and XPath 2.0 languages:

[XQuery 1.0: An XML Query Language] introduces the XQuery 1.0 language, defines its capabilities from a user-centric view, and defines the language syntax.

[XML Path Language (XPath) 2.0] introduces the XPath 2.0 language, defines its capabilities from a user-centric view, and defines the language syntax.

[Functions and Operators] lists the functions and operators defined for the [XPath/XQuery] language and specifies the required types of their parameters and return value.

[Data Model] formally specifies the data model used by [XPath/XQuery] to represent the content of XML documents. The [XPath/XQuery] language is formally defined by operations on this data model.

[Data Model Serialization] specifies how [XPath/XQuery] data model values are serialized into XML.

The scope and goals for the [XPath/XQuery] language are discussed in the charter of the W3C [XSL/XML Query] Working Group and in the [XPath/XQuery] requirements [XML Query 1.0 Requirements].

This document defines the semantics of [XPath/XQuery] by giving a precise formal meaning to each of the expressions of the [XPath/XQuery] specification in terms of the [XPath/XQuery] data model. This document assumes that the reader is already familiar with the [XPath/XQuery] language. This document defines the formal semantics for XPath 2.0 only when the XPath 1.0 backward compatibility rules are not in effect.

Two important design aspects of [XPath/XQuery] are that it is functional and that it is typed. These two aspects play an important role in the [XPath/XQuery] Formal Semantics.

[XPath/XQuery] is a functional language. [XPath/XQuery] is built from expressions, rather than statements. Every construct in the language (except for the XQuery query prolog) is an expression and expressions can be composed arbitrarily. The result of one expression can be used as the input to any other expression, as long as the type of the result of the former expression is compatible with the input type of the latter expression with which it is composed. Another characteristic of a functional language is that variables are always passed by value, and a variable's value cannot be modified through side effects.

[XPath/XQuery] is a typed language. Types can be imported from one or more XML Schemas that describe the input documents and the output document, and the [XPath/XQuery] language can then perform operations based on these types. In addition, [XPath/XQuery] supports static type analysis. Static type analysis infers the output type of an expression based on the type of its input expressions. In addition to inferring the type of an expression for the user, static typing allows early detection of type errors, and can be used as the basis for certain classes of optimization. The [XPath/XQuery] type system captures most of the features of [Schema Part 1], including global and local element and attribute declarations, complex and simple type definitions, named and anonymous types, derivation by restriction, extension, list and union, substitution groups, and wildcard types. It does not model uniqueness constraints and facet constraints on simple types.

This document is organized as follows. [2 Preliminaries] introduces the notations used to define the [XPath/XQuery] Formal Semantics. These include the formal notations for values in the [XPath/XQuery] data model and for types in XML Schema. The next three sections: [3 Basics], [4 Expressions], and [5 Modules and Prologs] have the same structure as the corresponding sections in the [XQuery 1.0: An XML Query Language] and [XML Path Language (XPath) 2.0] documents. This allows the reader to quickly find the formal definition of a particular language construct. [3 Basics] defines the semantics for basic [XPath/XQuery] concepts, and [4 Expressions] defines the dynamic and static semantics of each [XPath/XQuery] expression. [5 Modules and Prologs] defines the semantics of the [XPath/XQuery] prolog. [7 Additional Semantics of Functions] defines the static semantics of several functions in [Functions and Operators] and gives the dynamic and static semantics of several supporting functions used in this document. The remaining sections, [8 Auxiliary Judgments] and [D Importing Schemas], contain material that supports the formal semantics of [XPath/XQuery]. [8 Auxiliary Judgments] defines formal judgments that relate data model values to types, that relate types to types, and that support the formal definition of validation. These judgments are used in the definition of expressions in [4 Expressions]. Lastly, [D Importing Schemas], specifies how XML Schema documents are imported into the [XPath/XQuery] type system and relates XML Schema types to the [XPath/XQuery] type system.

1.1 Normative and Informative Sections

Certain aspects of language processing are described in this specification as implementation-defined or implementation-dependent.

[Definition: Implementation-defined indicates an aspect that may differ between implementations, but must be specified by the implementor for each particular implementation.]

[Definition: Implementation-dependent indicates an aspect that may differ between implementations, is not specified by this or any W3C specification, and is not required to be specified by the implementor for any particular implementation.]

A language aspect described in this specification as implementation-defined or implementation dependent may be further constrained by the specifications of a host language in which XPath or XQuery is embedded.

This document contains the normative static semantics of [XPath/XQuery]. The static semantics rules in [3 Basics], [4 Expressions], [5 Modules and Prologs], and [7 Additional Semantics of Functions] are normative. [3.1.1 Static Context] is normative, because it defines the static context used in the static typing rules. [8 Auxiliary Judgments] is normative, because it contains all the judgments necessary for defining SequenceType Matching.

The dynamic semantics of [XPath/XQuery] are normatively defined in [XQuery 1.0: An XML Query Language] and [XML Path Language (XPath) 2.0]. In this document, the dynamic semantic rules in [3 Basics], [4 Expressions], and [5 Modules and Prologs], the examples, and the material labeled as "Note" are provided for explanatory purposes and are not normative.

The mapping rules from XML Schema to the XQuery type system provided in [D Importing Schemas], and the formal semantics of XML Schema validation in [F Auxiliary Judgments for Validation] are informative and do not handle every feature of XML Schema.

2 Preliminaries

This section provides the background necessary to understand the Formal Semantics, introduces the notations that are used, and explains its relationship to other documents.

2.1 Introduction to the Formal Semantics

Why a Formal Semantics? The goal of the formal semantics is to complement the [XPath/XQuery] specification ([XQuery 1.0: An XML Query Language] and [XML Path Language (XPath) 2.0]), by defining the meaning of [XPath/XQuery] expressions with mathematical rigor.

A rigorous formal semantics clarifies the intended meaning of the English specification, ensures that no corner cases are left out, and provides a reference for implementation.

Why use formal notations? Rigor is achieved by the use of formal notations to represent [XPath/XQuery] objects such as expressions, XML values, and XML Schema types, and by the systematic definition of the relationships between those objects to reflect the meaning of the language. In particular, the dynamic semantics relates [XPath/XQuery] expressions to the XML value to which they evaluate, and the static semantics relates [XPath/XQuery] expressions to the XML Schema type that is inferred for that expression.

The Formal Semantics uses several kinds of formal notations to define the relationships between [XPath/XQuery] expressions, XML values, and XML Schema types. This section introduces the notations for judgments, inference rules, and mapping rules as well as the notation for environments, which implement the dynamic and static contexts. The reader already familiar with these notations can skip this section and continue with [2.3 XML Values].

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

[33 (XQuery)]   
FLWORExpr XQ
   ::=   
(ForClause | LetClause)+ WhereClause? OrderByClause? "return" ExprSingle

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

[4 (XPath)]   
ForExpr XP
   ::=   
SimpleForClause "return" ExprSingle

XQuery Core grammar productions describe the XQuery Core. The Core grammar is given in [A Normalized core and formal grammars]. Core productions are identified by a number, which corresponds to their number in [A Normalized core and formal grammars], 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

[24 (Core)]   
FLWORExpr
   ::=   
(ForClause | LetClause) "return" ExprSingle

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

[39 (Formal)]   
Definition
   ::=   
("define" "element" ElementName OptSubstitution OptNillable TypeReference)
| ("define" "attribute" AttributeName TypeReference)
| ("define" "type" TypeName TypeDerivation)

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

Object is a positive integer

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

Expr => Value

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

The judgment

Expr : Type

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. For instance, the judgment

Axis has principal PrincipalNodeKind

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. Symbols are chosen to reflect a judgment's meaning, and are written in bold fonts. For example, 'is a positive integer', '=>' and ':' are symbols, the second and third of which should be read "yields", and "has type" respectively.

Patterns are used to represent objects, constructed from a given grammar production. In patterns, italicized words usually 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 if and only if 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

Color in { blue, green }

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

In some cases, a judgment may use the "=" sign to indicate that a given value is equal to another value, or that a pattern is equal to a given value. For instance, the judgment

Color = blue

holds if the pattern Color has the value blue.

An index to all the judgments used in this specification is provided in [B Index of judgments].

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] dynamic context, and a static environment (statEnv), which models the [XPath/XQuery] 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

dynEnv |-  Expr => Value

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₁ ; ... ; symboln => objectn ) " 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(symboln => objectn)".

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 new environment is used for the evaluation of the expression $x + 2. Then this second environment is updated 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:

premise₁ ... premisen

conclusion

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 premisen

THEN conclusion

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

$x => 0      3 => 3

$x + 3 => 3

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:

3 => 3

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 $VarName that yields the integer value Integer, adding '0' yields the same integer value:

$VarName => Integer

$VarName + 0 => Integer

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, in the context of a particular instantiation of a rule, one can talk about "the value of $VarName" instead of the value bound to the first (second, etc) occurrence of $VarName.

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

statEnv |-  Expr₁ : Type₁      statEnv |-  Expr₂ : Type₂

statEnv |-  Expr₁ , Expr₂ : Type₁, Type₂

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.

statEnv |-  VarName of var expands to expanded-QName

statEnv |-  Expr₁ : Type₁      statEnv + varType(expanded-QName => Type₁)  |-  Expr₂ : Type₂

statEnv |-  let $VarName := Expr₁ return Expr₂ : Type₂

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.

In some cases, ellipses may be used in inference rules to handle an arbitrary number of judgments. In those cases, some of the patterns may have indices as subscript. If the same index is used several times within the same rule, the number of judgment in each case must be the same. For instance, the following rule holds for any number of expressions, from Expr₁ to Exprn, with the same number of types Type₁ to Typen.

statEnv |-  QName of func expands to expanded-QName

statEnv |-  Expr₁ : Type₁

...

statEnv |-  Exprn : Typen

statEnv  |-  expanded-QName(Type₁,...,Typen) : Type

statEnv  |-  QName (Expr₁,...,Exprn) : Type

This inference rule is equivalent to having an unbounded number of rules, the first of which has 1 judgment, the second of which has 2 judgments, etc. For instance, the above rule holds if and only if one of the following rules hold.

statEnv |-  QName of func expands to expanded-QName

statEnv |-  Expr₁ : Type₁

statEnv  |-  expanded-QName(Type₁) : Type

statEnv  |-  QName (Expr₁) : Type

or

statEnv |-  QName of func expands to expanded-QName

statEnv |-  Expr₁ : Type₁

statEnv |-  Expr₂ : Type₂

statEnv  |-  expanded-QName(Type₁,Type₂) : Type

statEnv  |-  QName (Expr₁,Expr₂) : Type

etc.

When ellipses are used, the value for the index always ranges from 1 to an arbitrary number n.

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 a particular judgment holds.

For a given judgment, if that judgment can be inferred to be true by applying any sequence of inferences based on premises which are known 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.

statEnv |-  Expr : Type

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.2 URIs, Namespaces, and Prefixes

The Formal Semantics does not formally specify the adjustment of relative URIs according to a base URI. All URIs used in this document are assumed to be absolute URIs.

The Formal Semantics uses the following namespace prefixes.

fn: for functions and operators from the [Functions and Operators] document.

xs: for XML Schema components and built-in types.

These prefixes are assumed to be bound to the appropriate URIs.

In addition, the Formal Semantics uses the following special prefixes for specification purposes.

dm: for accessors of the [Data Model].

op: for operators in [Functions and Operators].

fs: for functions and types defined in the formal semantics.

These prefixes are always italicized to emphasize that the corresponding functions, variables, and types are abstract: they are not and cannot be made accessible in [XPath/XQuery]. None of these special prefixes are given an explicit URI, but they behave as if they had one for the purposes of namespace resolution.

2.3 XML Values

The [XPath/XQuery] language is defined over values of the [XPath/XQuery] data model. The [XPath/XQuery] data model is defined normatively in [Data Model]. We define the formal notation that is used in this document to describe and manipulate values in inference rules. Formal values are used for specification purposes only and are not exposed to the [XPath/XQuery] user.

This section gives the grammar for formal values, along with a summary of the corresponding data model properties. In the context of this document, all constraints on values that are specified in [Data Model] are assumed to hold.

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], xs:untypedAtomic, or xs: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 annotationXQ and contain a complex value or a simple value. Attribute nodes have a type annotationXQ and contain a simple value. Text nodes always contain one string value of type xs: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 annotationXQ 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

[7 (Formal)]   
Value
   ::=   
Item
| (Value "," Value)
| ("(" ")")

[21 (Formal)]   
Item
   ::=   
NodeValue
| AtomicValue

[22 (Formal)]   
AtomicValue
   ::=   
AtomicValueContent TypeAnnotation?

[1 (Formal)]   
AtomicValueContent
   ::=   
String
| Boolean
| Decimal
| Float
| Double
| Duration
| DateTime
| Time
| Date
| GYearMonth
| GYear
| GMonthDay
| GDay
| GMonth
| HexBinary
| Base64Binary
| AnyURI
| expanded-QName
| NOTATION

[2 (Formal)]   
TypeAnnotation
   ::=   
"of" "type" TypeName

[9 (Formal)]   
ElementValue
   ::=   
"element" ElementName "nilled"? TypeAnnotation? "{" Value "}" ("{" NamespaceBindings "}")?

[10 (Formal)]   
AttributeValue
   ::=   
"attribute" AttributeName TypeAnnotation? "{" SimpleValue "}"

[8 (Formal)]   
SimpleValue
   ::=   
AtomicValue
| (SimpleValue "," SimpleValue)
| ("(" ")")

[11 (Formal)]   
DocumentValue
   ::=   
"document" "{" Value "}"

[13 (Formal)]   
CommentValue
   ::=   
"comment" "{" String "}"

[14 (Formal)]   
ProcessingInstructionValue
   ::=   
"processing-instruction" NCName "{" String "}"

[12 (Formal)]   
TextValue
   ::=   
"text" "{" String "}"

[20 (Formal)]   
NodeValue
   ::=   
ElementValue
| AttributeValue
| DocumentValue
| TextValue
| CommentValue
| ProcessingInstructionValue

[3 (Formal)]   
ElementName
   ::=   
QName

[6 (Formal)]   
AttributeName
   ::=   
QName

[23 (Formal)]   
TypeName
   ::=   
QName

[15 (Formal)]   
NamespaceBindings
   ::=   
NamespaceBinding ("," NamespaceBinding)*

[17 (Formal)]   
NamespaceBinding
   ::=   
"namespace" NCName "{" AnyURI "}"

Notation

In the production for AtomicValueContent, each symbol in the right-hand side corresponds to one of the primitive datatypes. For example, String corresponds to xs:string, and Boolean corresponds to xs:boolean. (The mapping is obvious, except that "expanded-QName" corresponds to xs:QName) Although there are no explicit productions for these symbols, we assume that each is a non-terminal that derives a set of syntactic objects, each of which corresponds to a value in the value space of the corresponding datatype. For instance, the non-terminal String derives a set of syntactic objects, which appear in examples as "", "a", "John", etc.; each one corresponds to a string value in the xs:string value space. For familiarity, these objects have been given the same appearance as StringLiterals from the XQuery and Core grammars; however, these are formal objects, with a distinct role in the FS.

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 annotationXQ xs:untyped, untyped attributes have the type annotationXQ xs:untypedAtomic, and untyped atomic values have the type annotationXQ xs: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.

Note:

In [XPath], the in-scope namespaces of an element node are represented by a collection of namespace nodes arranged on a namespace axis, which is optional and deprecated in [XML Path Language (XPath) 2.0]. XQuery does not support the namespace axis and does not represent namespace bindings in the form of nodes.

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 xs:untyped {
    text { "The cat weighs " },
    element weight of type xs:untyped {
      attribute units of type xs:untypedAtomic {
        "lbs" of type xs: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 xs:untyped {
    attribute xsi:type of type xs:untypedAtomic {
      "xs:integer" of type xs: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 xs: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 xs: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 xs:untyped {
    attribute xsi:nil of type xs:untypedAtomic { "true" of type xs: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 xs: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 The [XPath/XQuery] Type System

The [XPath/XQuery] type system is used in the specification of the dynamic and of the static semantics of [XPath/XQuery]. This section introduces formal notations for describing types.

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 [D 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

[25 (Formal)]   
FormalItemType
   ::=   
AtomicTypeName | NodeType

[28 (Formal)]   
AtomicTypeName
   ::=   
TypeName

[26 (Formal)]   
NodeType
   ::=   
DocumentType
| AttributeType
| ElementContentType

[27 (Formal)]   
ElementContentType
   ::=   
ElementType
| "comment"
| "processing-instruction"
| "text"

[29 (Formal)]   
ElementType
   ::=   
"element" ElementNameOrWildcard OptTypeSpecifier

[4 (Formal)]   
ElementNameOrWildcard
   ::=   
QName | "*"

[5 (Formal)]   
AttributeNameOrWildcard
   ::=   
QName | "*"

[77 (Formal)]   
OptTypeSpecifier
   ::=   
TypeSpecifier?

[30 (Formal)]   
TypeSpecifier
   ::=   
OptNillable TypeReference

[31 (Formal)]   
AttributeType
   ::=   
"attribute" AttributeNameOrWildcard OptTypeReference

[75 (Formal)]   
OptNillable
   ::=   
Nillable?

[32 (Formal)]   
Nillable
   ::=   
"nillable"

[78 (Formal)]   
OptTypeReference
   ::=   
TypeReference?

[36 (Formal)]   
TypeReference
   ::=   
"of" "type" TypeName

[45 (Formal)]   
DocumentType
   ::=   
"document" ("{" Type "}")?

An element or attribute type has a name or wildcard, 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. "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

[24 (Formal)]   
Type
   ::=   
FormalItemType
| (Type OccurrenceIndicator)
| (Type "&" Type)
| (Type "," Type)
| (Type "|" Type)
| "empty"
| "none"
| ("(" Type ")")

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.

# | Operator
1 | | (choice)
2 | & (interleaving)
3 | , (sequence)
4 | *, +, ? (occurrence)

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)*

Notation

The grammar for Type describe above is general enough to capture type infered for arbitrary expression, as well as to represent the content of an in [Schema Part 1]. In a few cases, inference rules rely on the fact that a given type is a type validly describing the content of an element. To capture those cases, we introduce the following auxiliary grammar productions to describe more precisely the attribute declarations and the content model for an element.

[42 (Formal)]   
AttributeModel
   ::=   
AttributeType
| (AttributeType "?")
| (AttributeModel "&" AttributeModel)
| ("(" ")")

[43 (Formal)]   
ElementModel
   ::=   
ElementType
| (ElementType "?")
| (ElementModel "&" ElementModel)
| ("(" ")")
| "none"

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

[40 (Formal)]   
Definitions
   ::=   
(Definition Definitions)?

[39 (Formal)]   
Definition
   ::=   
("define" "element" ElementName OptSubstitution OptNillable TypeReference)
| ("define" "attribute" AttributeName TypeReference)
| ("define" "type" TypeName TypeDerivation)

[76 (Formal)]   
OptSubstitution
   ::=   
Substitution?

[41 (Formal)]   
Substitution
   ::=   
"substitutes" "for" ElementName

[33 (Formal)]   
TypeDerivation
   ::=   
ComplexTypeDerivation | AtomicTypeDerivation

[34 (Formal)]   
ComplexTypeDerivation
   ::=   
Derivation? OptMixed "{" Type? "}"

[35 (Formal)]   
AtomicTypeDerivation
   ::=   
"restricts" AtomicTypeName

[37 (Formal)]   
Derivation
   ::=   
("restricts" TypeName)
| ("extends" TypeName)

[74 (Formal)]   
OptMixed
   ::=   
Mixed?

[38 (Formal)]   
Mixed
   ::=   
"mixed"

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.

Note the type system allows recursive types, following the rules defined in [Schema Part 1].

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

2.5 Functions and operators

The [Functions and Operators] document defines built-in functions available in [XPath/XQuery]. A number of these functions are used to define the [XPath/XQuery] semantics; those functions are listed in [C.1 Functions and Operators used in the Formal Semantics].

Many functions in the [Functions and Operators] document are generic: they perform operations on arbitrary components of the data model, e.g., any kind of node, or any sequence of items. For instance, the fn:unordered returns its input sequence in an implementation-dependent order. The signature of the fn:unordered function takes arbitrary items as input and output:

  fn:unordered($sourceSeq as item()*) as item()*

As defined, this signature provides little useful type information. For such functions, better type information can often be obtained by having the output type depend on the type of input parameters. For instance, if the function fn:unordered is applied on a sequence of a elements, the result is also a sequence of a elements.

In order to provide better static typing for those functions, specific static typing rules are given in [7 Additional Semantics of Functions].

3 Basics

The organization of this section parallels the organization of Section 2 BasicsXQ.

3.1 Expression Context

Introduction

The expression context for a given expression consists of all the information that can affect the result of the expression. This information is organized into the static context and the dynamic context. This section specifies the environments that represent the context information used by [XPath/XQuery] expressions.

3.1.1 Static Context

Notation

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

[85 (Formal)]    | FunctionSig |    ::=    | "declare" "function" expanded-QName "(" TypeList? ")" "as" SequenceType
[86 (Formal)]    | TypeList |    ::=    | SequenceType ("," Type)*

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:

statEnv.xpath1.0_compatibility

The statEnv.xpath1.0_compatibility environment component designates the XPath 1.0 compatibility flag in the [XPath/XQuery] static context. It specifies whether the semantic rules for backward compatibility with XPath 1.0 are in effect. This document defines the formal semantics for XPath 2.0 only when the XPath 1.0 backward compatibility rules are not in effect.

statEnv.namespace

The statEnv.namespace environment component designates the statically known namespaces in the [XPath/XQuery] static context.

The statEnv.namespace environment component maps a namespace prefix (NCName) onto a namespace kind and a namespace URI (AnyURI), the null namespace (#NULL-NAMESPACE), or (#UNDECLARED). The namespace kind is either passive or active. The namespace kind determines whether a namespace node is created for an element during element construction. The (#UNDECLARED) value may be used to indicate that the prefix has been undeclared, and may occur only if the implementation supports [XML Names 1.1].

statEnv.default_elem_namespace

The statEnv.default_elem_namespace environment component designates the default element/type namespace in the [XPath/XQuery] static context.

The statEnv.default_elem_namespace environment component contains a namespace URI (a AnyURI) or the null namespace (#NULL-NAMESPACE) and is used for any unprefixed QName appearing in a position where an element or type name is expected.

statEnv.default_function_namespace

The statEnv.default_function_namespace environment component designates the default function namespace in the [XPath/XQuery] static context.

The statEnv.default_function_namespace environment component contains a namespace URI (a AnyURI) or the null namespace (#NULL-NAMESPACE) and is used for any unprefixed QName appearing as the function name in a function call.

statEnv.typeDefn

The statEnv.typeDefn environment component designates the in-scope schema types in the [XPath/XQuery] static context.

The statEnv.typeDefn environment component maps expanded type names (expanded TypeNames) onto their type definition (Definition). A type name may be globally declared or anonymous.

statEnv.elemDecl

The statEnv.elemDecl environment component designates the in-scope element declarations in the [XPath/XQuery] static context.

The statEnv.elemDecl environment component maps expanded element names (expanded ElementNames) onto their declaration (Definition).

statEnv.attrDecl

The statEnv.attrDecl environment component designates the in-scope attribute declarations in the [XPath/XQuery] static context.

The statEnv.attrDecl environment component maps expanded attribute names (expanded AttributeNames) onto their declaration (Definition).

statEnv.varType

The statEnv.varType environment component designates the in-scope variables in the [XPath/XQuery] static context.

The statEnv.varType environment component maps expanded variable names (expanded VarName) to their static type (Type).

The context item static type in the [XPath/XQuery] static context is represented by the binding of the variable $fs:dot to its corresponding type in statEnv.varType.

statEnv.funcType

The statEnv.funcType environment component designates the function signatures in the [XPath/XQuery] static context.

The statEnv.funcType environment component stores the static type signatures of functions. Because [XPath/XQuery] allows multiple functions with the same name differing in the number of parameters, this environment component maps an expanded QName and an arity to a function signature FunctionSig.

statEnv.collations

The statEnv.collations environment component designates the statically known collations in the [XPath/XQuery] static context.

The statEnv.collations environment component maps a unique namespace URI (a AnyURI) to a pair of functions: the first function takes a set of strings and returns a sequence containing those strings in sorted order; and the second function takes two strings, returns true if they are considered equal, and false if not.

statEnv.defaultCollation

The statEnv.defaultCollation environment component designates the default collation in the [XPath/XQuery] static context.

The statEnv.defaultCollation environment component is a pair of functions as described in statEnv.collations above.

statEnv.constructionMode

The statEnv.constructionMode environment component designates the construction mode in the [XPath/XQuery] static context.

The statEnv.constructionMode environment component is one of preserve or strip.

statEnv.orderingMode

The statEnv.orderingMode environment component designates the ordering mode in the [XPath/XQuery] static context.

The statEnv.orderingMode environment component is one of ordered or unordered.

statEnv.defaultEmptySequenceOrder

The statEnv.defaultEmptySequenceOrder environment component designates the default order for empty sequences in the [XPath/XQuery] static context.

The statEnv.defaultEmptySequenceOrder environment component controls whether an empty sequence is interpreted as the greatest value or as the least value during processing of an order by clause in a FLWOR expression. Its value may be greatest or least.

statEnv.boundarySpace

The statEnv.boundarySpace environment component designates the boundary-space policy in the [XPath/XQuery] static context.

The statEnv.boundarySpace environment component controls the processing of boundary whitespace by element constructors. Its value may be preserve or strip.

statEnv.copyNamespacesMode

The statEnv.copyNamespacesMode environment component designates the copy-namespaces mode in the [XPath/XQuery] static context.

The statEnv.copyNamespacesMode environment component controls the namespace bindings that are assigned when an existing element node is copied by an element constructor. Its value consists of two parts: preserve or no-preserve, and inherit or no-inherit.

statEnv.baseURI

The statEnv.baseURI environment component designates the base URI in the [XPath/XQuery] static context.

The statEnv.baseURI environment component contains a unique namespace URI (a AnyURI).

statEnv.docType

The statEnv.docType environment component designates the statically known documents in the [XPath/XQuery] static context. It contains the static type for the input documents, and is used to provide the static type to the fn:doc function.

The statEnv.docType environment component contains bindings from input URIs (a AnyURI) to types (a Type).

statEnv.collectionType

The statEnv.collectionType environment component designates the statically known collections in the [XPath/XQuery] static context. It contains the static type for the input collections, and is used to provide the static type to the fn:collection function.

The statEnv.collectionType environment component contains bindings from input URIs (a AnyURI) to types (a Type).

statEnv.defaultCollectionType

The statEnv.defaultCollectionType environment component designates the statically known default collection type in the [XPath/XQuery] static context. It contains the static type for the default collection, and is used to provide the static type to the fn:collection function when called with no arguments.

The statEnv.defaultCollectionType environment component contains type (a Type).

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

An initial environment is set up 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 ComponentsXQ and Section C Context ComponentsXP 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.

dynEnv |-  URILiteral has atomic value AnyURI

statEnv + namespace(NCName => (passive, AnyURI))  |-  Expr : Type

statEnv |-  declare namespace NCName = URILiteral; Expr : Type

This rule reads as follows: "the phrase on the bottom (a namespace declaration in the query prolog followed by an expression) is well-typed (accepted by the static typing rules) within an environment statEnv if the expression 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 AnyURI, the helper function fs:get_static_ns_from_items(statEnv, Value) returns the in-scope namespace that corresponds to AnyURI. This is a reverse-lookup on statEnv.namespace by AnyURI.

3.1.1.1 Resolving QNames to Expanded QNames

A common use of the static environment is to expand a QName by looking up the URI that corresponds to the QName's namespace prefix in the statEnv.namespace environment component and by constructing an expanded-QName DM, which contains the URI and the QName's local part. Element and type names may be in the null namespace, that is, there is no URI associated with their namespace prefix. The null namespace is denoted by the special value #NULL-NAMESPACE.

The auxiliary judgments below expand an element, type, attribute, variable, or function QName by looking up the namespace prefix in statEnv.namespace or, if the QName is unqualified, by using the appropriate default namespace.

Notation

The judgment

statEnv |-  QName of elem/type expands to expanded-QName

holds when the element or type QName expands to the given expanded QName.

The judgment

statEnv |-  QName of attr expands to expanded-QName

holds when the attribute QName expands to the given expanded QName.

We use Variable to denote the expanded QNames of variables.

The judgment

statEnv |-  QName of var expands to Variable

holds when the variable QName expands to the given expanded QName.

The judgment

statEnv |-  QName of func expands to expanded-QName

holds when the function QName expands to the given expanded QName.

Semantics

Note that none of the inference rules can infer a resolved name in the case a given namespace prefix is bound to the (#UNDECLARED) value. As a result, namespace resolution will fail if the implementation supports [XML Names 1.1] and a given namespace prefix has been undeclared.

An element or type QName consisting of a prefix NCName and a local part NCName expands to the URI (or the null namespace) corresponding to that prefix and the local part.

statEnv.namespace(NCName₁) = (NamespaceKind,AnyURI-or-#NULL-NAMESPACE)

statEnv |-  NCName₁:NCName₂ of elem/type expands to (AnyURI-or-#NULL-NAMESPACE, NCName₂)

An element or type QName consisting only of a local part NCName expands to the default element/type namespace and the local part.

statEnv.default_elem_namespace = AnyURI-or-#NULL-NAMESPACE

statEnv |-  NCName of elem/type expands to (AnyURI-or-#NULL-NAMESPACE, NCName)

An attribute QName consisting of a prefix NCName and a local part NCName expands to the URI (or the null namespace) corresponding to the prefix and the local part.

statEnv.namespace(NCName₁) = (NamespaceKind,AnyURI-or-#NULL-NAMESPACE)

statEnv |-  NCName₁:NCName₂ of attr expands to (AnyURI-or-#NULL-NAMESPACE, NCName₂)

An attribute QName consisting only of a local part NCName expands to the null namespace and the local part.

statEnv |-  NCName of attr expands to (#NULL-NAMESPACE, NCName)

A variable QName consisting of a prefix NCName and a local part NCName expands to the URI that corresponds to the prefix and the local part.

statEnv.namespace(NCName₁) = (NamespaceKind,AnyURI)

statEnv |-  NCName₁:NCName₂ of var expands to (AnyURI, NCName₂)

A variable QName consisting only of a local part NCName expands to the null namespace and the local part.

statEnv |-  NCName of var expands to (#NULL-NAMESPACE, NCName)

A function QName consisting of a prefix NCName and a local part NCName expands to the URI that corresponds to the prefix and the local part.

statEnv.namespace(NCName₁) = (NamespaceKind,AnyURI)

statEnv |-  NCName₁:NCName₂ of func expands to (AnyURI, NCName₂)

A function QName consisting only of a local part NCName expands to the default function namespace URI and the local part.

statEnv.default_function_namespace = AnyURI

statEnv |-  NCName of func expands to (AnyURI, NCName)

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:

dynEnv.varValue

The dynEnv.varValue environment component corresponds to the variable values, the context item, the context position and the context size in the [XPath/XQuery] evaluation context.

The dynamic value environment component maps an expanded variable name (expanded VarName) to the variable's value (Value) or to the value #IMPORTED(AnyURI), if the variable is defined in the imported module with namespace AnyURI.

dynEnv.funcDefn

The dynEnv.funcDefn environment component corresponds to the function implementations (or definition) part of the [XPath/XQuery] dynamic context.

The dynEnv.funcDefn environment component maps an expanded function name and parameter signature of the form "expanded-QName (Type₁, ..., Typen)" to the remainder of the corresponding function definition. If the function is defined in [Functions and Operators], the function definition is the value #BUILT-IN. If the function is externally defined, the function definition is the value #EXTERNAL. If the function is defined in the imported module with namespace AnyURI, the function definition is the value #IMPORTED(AnyURI). If the function is locally declared, the function definition is of the form "(Expr, Variable₁,..., Variablen)", where Expr is the function body and Variable₁, ..., Variablen are the function parameters.

The initial function environment component (dynEnvDefault.funcDefn) maps the signatures of the internal functions defined in [C.2 Mapping of Overloaded Internal Functions] and the signatures of the functions defined in [Functions and Operators] to #BUILT-IN.

dynEnv.dateTime

The dynEnv.dateTime environment component corresponds to the current dateTime in the [XPath/XQuery] dynamic context.

dynEnv.timezone

The dynEnv.timezone environment component corresponds to the implicit timezone in the [XPath/XQuery] dynamic context and is used by the timezone related functions in [Functions and Operators].

dynEnv.docValue

The dynEnv.docValue environment component corresponds to the available documents in the [XPath/XQuery] dynamic context. It contains the document nodes corresponding to input documents, and is used to provide the dynamic value of the fn:doc function.

The dynEnv.docValue environment component contains bindings from input URIs (a AnyURI) to documents (a DocumentValue).

dynEnv.collectionValue

The dynEnv.collectionValue environment component corresponds to the available collections in the [XPath/XQuery] dynamic context. It contains the root nodes corresponding to the input collections, and is used to provide the dynamic value of the fn:collection function.

The dynEnv.collectionValue environment component contains bindings from input URIs (a AnyURI) to a sequence of nodes.

dynEnv.defaultCollectionValue

The dynEnv.defaultCollectionValue environment component corresponds to the default collection in the [XPath/XQuery] dynamic context. It contains the sequence of nodes corresponding to the default collection, and is used to provide the dynamic value of the fn:collection function when called with no arguments.

The dynEnv.defaultCollectionValue environment component contains a sequence of nodes.

The initial values for the dynamic context are defined in Section C Context ComponentsXQ and Section C Context ComponentsXP. 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:

Built-in Variable   | Represents:
$fs:dot | context item
$fs:position | context position
$fs:last | context size

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. Note that the type for those variables is obtained as for any other variables. As expected the type of $fs:position and $fs:last is always xs:integer while the type of $fs:dot depends on the context in which it is being used.

3.2 Processing Model

This section reviews the processing model for [XPath/XQuery]. The [XPath/XQuery] processing model is defined normatively in Section 2.2 Processing ModelXQ. This section also explains how the main notations (normalization rules, static typing rules, and dynamic evaluation rules) relate to the phases in that processing model.

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. Typically, each phase consumes the result of the previous phase and generates output for the next phase. When processing query prologs, these phases may be mutually dependent (See [5 Modules and Prologs]). 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:

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.

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.

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 and formal grammars].

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 mapping rules].

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.

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 well-typed, 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 static typing rules over a given expression.

If the [expression/query] is not well-typed, 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).

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.

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 dynamic evaluation rules over a given expression. 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:

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 [D Importing Schemas].

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.

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 mapping rules

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 [D 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:

[Object]Subscript, premises

==

Mapped Object

The original "object", and an optional list of premises, 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. For instance, the mapping rule [Expr]FunctionArgument(Type) is used in the normalization of [4.1.5 Function Calls] and passes a sequence type as a parameter during normalization.

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

statEnv |- premises

statEnv |-  [Object] Subscript = Mapped Object

Most normalization rules have no premises, so they are omitted. 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:

[Expr]Expr

==

CoreExpr

which indicates that the expression Expr is normalized to the expression CoreExpr in the [XPath/XQuery] Core (with the implied statEnv). Note that Expr within the square brackets are the expression being normalized, while the Expr in the subscript indicate that this is the main normalization rule that applies to expressions. For instance, here is the normalization rule applied to the literal integer 1.

[1]Expr

==

1

To simplify the specification in some cases, some further normalization may be used on the right-hand side of a normalization rule. For instance, the following normalization rules for the / operator applies normalization to the expanded expression on the right-hand side.

[/]Expr

==

[(fn:root(self::node()) treat as document-node())]Expr

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 static typing rules, which relate [XPath/XQuery] expressions to types and specify under what conditions an expression is well typed.

Notation

The judgment

statEnv |-  Expr : Type

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 literal '3' has 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 typing 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:

statEnv |-  Expr₁ : xs:boolean      statEnv |-  Expr₂ : Type₂      statEnv |-  Expr₃ : Type₃

statEnv |-  if (Expr₁) then Expr₂ else Expr₃ : ( Type₂ | Type₃ )

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 part after the |- and before : in the judgment 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 judgment 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 judgments 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 typing rules recursively to those sub-expressions), 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. Static type inference is recursive, following the abstract syntax of the [expression/query]. At each point in the recursion, an inference rule whose conclusion has a structure that matches that of the premise in question is sought. If all the premises of a rule cannot be satisfied, then the static type inference has failed for the given expression, and the [expression/query] is not well-typed.

3.2.4 Dynamic evaluation judgment

The dynamic, or operational, semantics is specified using dynamic evaluation 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

statEnv; dynEnv |-  Expr => Value

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 evaluation rules, but it is assumed to be available.

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

3.3 Error Handling

Expressions can raise errors during static analysis or dynamic evaluation. The [Functions and Operators] [XQuery 1.0: An XML Query Language], and [XML Path Language (XPath) 2.0] specify the conditions under which an expression or operator raises an error. The user may raise an error explicitly by calling the fn:error function, which takes an optional item as an argument.

This document does not describe formally the conditions under which dynamic errors are raised. Notably, it does not specify the error codes or the rules about errors and optimization, as described in [XQuery 1.0: An XML Query Language]. Instead, this document describe the rules necessary to statically detect the subset of the [XPath/XQuery] dynamic errors known as type errorXQ.

3.4 Concepts

[XPath/XQuery] is most generally used to process documents. The representation of a document is normatively defined in [Data Model]. The functions used to access documents and collections are normatively defined in [Functions and Operators].

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 several functions that provide access to input data, described in Section 2.4.4 Input SourcesXQ. 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 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 Types

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 xs:anyAtomicType, xs:untypedAtomic and xs:untyped and the duration subtypes xs:yearMonthDuration and xs: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 )*,
    ( xs: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 {
    xs: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 xs:anyAtomicType reflects the semantics of xs:anyAtomicType in the [XPath/XQuery] type system.]

  define type xs: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
    | xs: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 xs:anyAtomicType
  define type xs:boolean      restricts xs:anyAtomicType
  define type xs:decimal      restricts xs:anyAtomicType
  define type xs:float        restricts xs:anyAtomicType
  define type xs:double       restricts xs:anyAtomicType
  define type xs:duration     restricts xs:anyAtomicType
  define type xs:dateTime     restricts xs:anyAtomicType
  define type xs:time         restricts xs:anyAtomicType
  define type xs:date         restricts xs:anyAtomicType
  define type xs:gYearMonth   restricts xs:anyAtomicType
  define type xs:gYear        restricts xs:anyAtomicType
  define type xs:gMonthDay    restricts xs:anyAtomicType
  define type xs:gDay         restricts xs:anyAtomicType
  define type xs:gMonth       restricts xs:anyAtomicType
  define type xs:hexBinary    restricts xs:anyAtomicType
  define type xs:base64Binary restricts xs:anyAtomicType
  define type xs:anyURI       restricts xs:anyAtomicType
  define type xs:QName        restricts xs:anyAtomicType
  define type xs:NOTATION     restricts xs:anyAtomicType

All of those primitive types derive from xs: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 xs:untypedAtomic is defined as follows.]

  define type xs:untypedAtomic restricts xs:anyAtomicType

Note that this rule does not indicate the value space of xs:untypedAtomic. By definition, xs: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 xs:untypedAtomic

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

  define type xs:untyped restricts xs:anyType {
    attribute * of type xs:untypedAtomic*,
    ( element * of type xs: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:NCName
  define type xs:IDREF              restricts xs:NCName
  define type xs:ENTITY             restricts xs:NCName
  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, xs:yearMonthDuration and xs:dayTimeDuration , are derived by restriction from xs:duration.]

  define type xs:yearMonthDuration restricts xs:duration
  define type xs: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 xs: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

[119 (XQuery)]   
SequenceType XQ
   ::=   
("empty-sequence" "(" ")")
| (ItemType OccurrenceIndicator?)

[121 (XQuery)]   
ItemType XQ
   ::=   
KindTest | ("item" "(" ")") | AtomicType

[120 (XQuery)]   
OccurrenceIndicator XQ
   ::=   
"?" | "*" | "+"

[122 (XQuery)]   
AtomicType XQ
   ::=   
QName

[123 (XQuery)]   
KindTest XQ
   ::=   
DocumentTest
| ElementTest
| AttributeTest
| SchemaElementTest
| SchemaAttributeTest
| PITest
| CommentTest
| TextTest
| AnyKindTest

[125 (XQuery)]   
DocumentTest XQ
   ::=   
"document-node" "(" (ElementTest | SchemaElementTest)? ")"

[133 (XQuery)]   
ElementTest XQ
   ::=   
"element" "(" (ElementNameOrWildcard ("," TypeName "?"?)?)? ")"

[135 (XQuery)]   
SchemaElementTest XQ
   ::=   
"schema-element" "(" ElementDeclaration ")"

[136 (XQuery)]   
ElementDeclaration XQ
   ::=   
ElementName

[129 (XQuery)]   
AttributeTest XQ
   ::=   
"attribute" "(" (AttribNameOrWildcard ("," TypeName)?)? ")"

[131 (XQuery)]   
SchemaAttributeTest XQ
   ::=   
"schema-attribute" "(" AttributeDeclaration ")"

[132 (XQuery)]   
AttributeDeclaration XQ
   ::=   
AttributeName

[134 (XQuery)]   
ElementNameOrWildcard XQ
   ::=   
ElementName | "*"

[138 (XQuery)]   
ElementName XQ
   ::=   
QName

[130 (XQuery)]   
AttribNameOrWildcard XQ
   ::=   
AttributeName | "*"

[137 (XQuery)]   
AttributeName XQ
   ::=   
QName

[139 (XQuery)]   
TypeName XQ
   ::=   
QName

[128 (XQuery)]   
PITest XQ
   ::=   
"processing-instruction" "(" (NCName | StringLiteral)? ")"

[127 (XQuery)]   
CommentTest XQ
   ::=   
"comment" "(" ")"

[126 (XQuery)]   
TextTest XQ
   ::=   
"text" "(" ")"

[124 (XQuery)]   
AnyKindTest XQ
   ::=   
"node" "(" ")"

Core Grammar

The Core grammar productions for sequence types are:

[76 (Core)]   
SequenceType
   ::=   
("empty-sequence" "(" ")")
| (ItemType OccurrenceIndicator?)

[78 (Core)]   
ItemType
   ::=   
KindTest | ("item" "(" ")") | AtomicType

[77 (Core)]   
OccurrenceIndicator
   ::=   
"?" | "*" | "+"

[79 (Core)]   
AtomicType
   ::=   
QName

[80 (Core)]   
KindTest
   ::=   
DocumentTest
| ElementTest
| AttributeTest
| SchemaElementTest
| SchemaAttributeTest
| PITest
| CommentTest
| TextTest
| AnyKindTest

[82 (Core)]   
DocumentTest
   ::=   
"document-node" "(" (ElementTest | SchemaElementTest)? ")"

[90 (Core)]   
ElementTest
   ::=   
"element" "(" (ElementNameOrWildcard ("," TypeName "?"?)?)? ")"

[92 (Core)]   
SchemaElementTest
   ::=   
"schema-element" "(" ElementDeclaration ")"

[93 (Core)]   
ElementDeclaration
   ::=   
ElementName

[86 (Core)]   
AttributeTest
   ::=   
"attribute" "(" (AttribNameOrWildcard ("," TypeName)?)? ")"

[88 (Core)]   
SchemaAttributeTest
   ::=   
"schema-attribute" "(" AttributeDeclaration ")"

[89 (Core)]   
AttributeDeclaration
   ::=   
AttributeName

[91 (Core)]   
ElementNameOrWildcard
   ::=   
ElementName | "*"

[95 (Core)]   
ElementName
   ::=   
QName

[87 (Core)]   
AttribNameOrWildcard
   ::=   
AttributeName | "*"

[94 (Core)]   
AttributeName
   ::=   
QName

[96 (Core)]   
TypeName
   ::=   
QName

[85 (Core)]   
PITest
   ::=   
"processing-instruction" "(" (NCName | StringLiteral)? ")"

[84 (Core)]   
CommentTest
   ::=   
"comment" "(" ")"

[83 (Core)]   
TextTest
   ::=   
"text" "(" ")"

[81 (Core)]   
AnyKindTest
   ::=   
"node" "(" ")"

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 evaluation or static typing rule requires it.

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.

[SequenceType]sequencetype

==

Type

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.

[ItemType OccurrenceIndicator]sequencetype

==

[ItemType]sequencetype OccurrenceIndicator

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

[empty-sequence()]sequencetype

==

empty

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

[AtomicType]sequencetype

==

AtomicType

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

[element()]sequencetype

==

element * of type xs:anyType

[element(*)]sequencetype

==

element * of type xs:anyType

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.

[element(*,TypeName)]sequencetype

==

element * of type TypeName

[element(*,TypeName?)]sequencetype

==

element * nillable of type TypeName

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.

[element(ElementName,TypeName)]sequencetype

==

element ElementName of type TypeName

[element(ElementName,TypeName?)]sequencetype

==

element ElementName nillable of type TypeName

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.

[element(ElementName)]sequencetype

==

element ElementName nillable of type xs:anyType

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

[schema-element(ElementName)]sequencetype

==

element ElementName

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

[attribute()]sequencetype

==

attribute * of type xs:anySimpleType

[attribute(*)]sequencetype

==

attribute * of type xs:anySimpleType

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

[attribute(*,TypeName)]sequencetype

==

attribute * of type TypeName

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

[attribute(AttributeName,TypeName)]sequencetype

==

attribute AttributeName of type TypeName

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

[schema-attribute(AttributeName)]sequencetype

==

attribute AttributeName

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

[document-node()]sequencetype

==

document { (element * of type xs:anyType | text | comment | processing-instruction)* }

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.

[document-node(ElementTest)]sequencetype

==

document { [ElementTest]sequencetype & ( processing-instruction | comment ) *}

[document-node(SchemaElementTest)]sequencetype

==

document { [SchemaElementTest]sequencetype & ( processing-instruction | comment ) *}

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

[processing-instruction()]sequencetype

==

processing-instruction

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.

[processing-instruction(StringLiteral) ]sequencetype

==

processing-instruction?

[processing-instruction(NCName)]sequencetype

==

processing-instruction?

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

[comment()]sequencetype

==

comment

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

[text()]sequencetype

==

text

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

[node()]sequencetype

==

(element * of type xs:anyType | attribute * of type xs:anySimpleType | text | document { (element * of type xs:anyType | text | comment | processing-instruction)* } | comment | processing-instruction)

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.

[item()]sequencetype

==

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

3.6 Comments

[151 (XQuery)]    | Comment XQ |    ::=    | "(:" (CommentContents | Comment)* ":)"
[159 (XQuery)]    | CommentContents XQ |    ::=    | (Char+ - (Char* ('(:' | ':)') Char*))

Comments are lexical constructs only, and have no effect on the meaning of the query, and therefore do not have any formal semantics.

3.7 XML-defined Terminals

The following terminals are defined by XML.

[152 (XQuery)]    | PITarget XQ |    ::=    | [http://www.w3.org/TR/REC-xml#NT-PITarget] XML
[153 (XQuery)]    | CharRef XQ |    ::=    | [http://www.w3.org/TR/REC-xml#NT-CharRef] XML
[154 (XQuery)]    | QName XQ |    ::=    | [http://www.w3.org/TR/REC-xml-names/#NT-QName] Names
[155 (XQuery)]    | NCName XQ |    ::=    | [http://www.w3.org/TR/REC-xml-names/#NT-NCName] Names
[156 (XQuery)]    | SXQ |    ::=    | [http://www.w3.org/TR/REC-xml#NT-S] XML
[157 (XQuery)]    | Char XQ |    ::=    | [http://www.w3.org/TR/REC-xml#NT-Char] XML

4 Expressions

This section gives the semantics of all the [XPath/XQuery] expressions. The organization of this section parallels the organization of Section 3 ExpressionsXQ.

[31 (XQuery)]   
Expr XQ
   ::=   
ExprSingle ("," ExprSingle)*

[32 (XQuery)]   
ExprSingle XQ
   ::=   
FLWORExpr
| QuantifiedExpr
| TypeswitchExpr
| IfExpr
| OrExpr

[1 (XPath)]   
XPath XP
   ::=   
Expr

For each expression, a short description and the relevant grammar productions are given. The semantics of an expression includes the normalization, static analysis, and dynamic evaluation phases. Recall that normalization rules translate [XPath/XQuery] syntax into Core syntax. In the sections that contain normalization rules, the Core grammar productions into which the expression is normalized are also provided. After normalization, sections on static type inference and dynamic evaluation define the static type and dynamic value for the Core expression.

Core Grammar

The Core grammar productions for expressions are:

[22 (Core)]   
Expr
   ::=   
ExprSingle ("," ExprSingle)*

[23 (Core)]   
ExprSingle
   ::=   
FLWORExpr
| QuantifiedExpr
| TypeswitchExpr
| IfExpr
| OrExpr

Static Type Analysis

During static analysis, it is a type error for an expression to have the empty type, except for the following expressions and function calls:

Empty parentheses (), which denote the empty sequence.

The fn:data function and all functions in the fs namespace applied to empty parentheses ().

Any function which returns the empty type.

The reason for these exceptions is that they are typically part of the result of normalizing a larger user-level expression and are used to capture the semantics of the user-level expression when applied to the empty sequence.

The rule below enforces the above constraints. It is a static type error, if the following conditions hold for a given expression Expr.

statEnv |-  Expr : Type

statEnv |-  Type <: empty

not(Expr is the empty parentheses () or fn:data or any fs function applied to empty parentheses ())

A static type error is raised for expression Expr

In general, static type errors are raised whenever there is no static typing rules which can compute the type of a given expression. This is the reason for the absence of a formal post-condition in this rules. There is indeed a rule that infers the type for expression Expr, however the inferred type is empty and still a static type error must be raised.

Example

The above rule is useful in catching common mistakes, such as the misspelling of an element or attribute name or referencing of an element or attribute that does not exist. For instance, the following path expression

  $x/title

raises a static type error if the type of variable $x does not include any title children elements.

4.1 Primary Expressions

Primary expressions are the basic primitives of the language. They include literals, variables, function calls, and the parenthesized expressions.

Primary Expressions

[84 (XQuery)]   
PrimaryExpr XQ
   ::=   
Literal | VarRef | ParenthesizedExpr | ContextItemExpr | FunctionCall | OrderedExpr | UnorderedExpr | Constructor

Core Grammar

The Core grammar production for primary expressions is:

Primary Expressions

[55 (Core)]   
PrimaryExpr
   ::=   
Literal | VarRef | ParenthesizedExpr | FunctionCall | OrderedExpr | UnorderedExpr | Constructor

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

[85 (XQuery)]    | Literal XQ |    ::=    | NumericLiteral | StringLiteral
[86 (XQuery)]    | NumericLiteral XQ |    ::=    | IntegerLiteral | DecimalLiteral | DoubleLiteral
[141 (XQuery)]    | IntegerLiteral XQ |    ::=    | Digits
[142 (XQuery)]    | DecimalLiteral XQ |    ::=    | ("." Digits) | (Digits "." [0-9]*)
[143 (XQuery)]    | DoubleLiteral XQ |    ::=    | (("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits
[144 (XQuery)]    | StringLiteral XQ |    ::=    | ('"' (PredefinedEntityRef | CharRef | EscapeQuot | [^"&])* '"') | ("'" (PredefinedEntityRef | CharRef | EscapeApos | [^'&])* "'")
[140 (XQuery)]    | URILiteral XQ |    ::=    | StringLiteral
[145 (XQuery)]    | PredefinedEntityRef XQ |    ::=    | "&" ("lt" | "gt" | "amp" | "quot" | "apos") ";"
[158 (XQuery)]    | Digits XQ |    ::=    | [0-9]+

Core Grammar

The Core grammar productions for literals are:

Literals

[56 (Core)]    | Literal |    ::=    | NumericLiteral | StringLiteral
[57 (Core)]    | NumericLiteral |    ::=    | IntegerLiteral | DecimalLiteral | DoubleLiteral
[98 (Core)]    | IntegerLiteral |    ::=    | Digits
[99 (Core)]    | DecimalLiteral |    ::=    | ("." Digits) | (Digits "." [0-9]*)
[100 (Core)]    | DoubleLiteral |    ::=    | (("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits
[101 (Core)]    | StringLiteral |    ::=    | ('"' (EscapeQuot | [^"])* '"') | ("'" (EscapeApos | [^'])* "'")
[97 (Core)]    | URILiteral |    ::=    | StringLiteral
[112 (Core)]    | Digits |    ::=    | [0-9]+

Notation

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

The judgment

dynEnv |-  Literal has atomic value AtomicValue

holds if the literal expression Literal 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.

[IntegerLiteral]Expr

==

IntegerLiteral

[DecimalLiteral]Expr

==

DecimalLiteral

[DoubleLiteral]Expr

==

DoubleLiteral

[StringLiteral]Expr

==

StringLiteral

Static Type Analysis

The static type of a literal expression is its corresponding atomic type.

statEnv |-  IntegerLiteral : xs:integer

statEnv |-  DecimalLiteral : xs:decimal

statEnv |-  DoubleLiteral : xs:double

statEnv |-  StringLiteral : xs:string

Dynamic Evaluation

In the dynamic semantics, a literal is evaluated by constructing an atomic value in the data model, using the has atomic value judgment defined above.

dynEnv |-  Literal has atomic value AtomicValue

dynEnv |-  Literal => AtomicValue

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

[87 (XQuery)]    | VarRef XQ |    ::=    | "$" VarName
[88 (XQuery)]    | VarName XQ |    ::=    | QName

Core Grammar

The Core grammar productions for variable references are:

Primary Expressions

[58 (Core)]    | VarRef |    ::=    | "$" VarName
[59 (Core)]    | VarName |    ::=    | QName

Normalization

Variable references are left unchanged through normalization.

[VarRef]Expr

==

VarRef

Static Type Analysis

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

statEnv |-  VarName of var expands to Variable

statEnv.varType(Variable) = Type

statEnv |-  $VarName : Type

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:

statEnv |-  VarName of var expands to Variable

dynEnv.varValue(Variable) = Value

dynEnv |-  $VarName => Value

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.

The notation AnyURI =>module_dynEnv dynEnv₁ is used to access a module context and is defined in [5.2 Module Declaration].

statEnv |-  VarName of var expands to Variable

dynEnv.varValue(Variable) = #IMPORTED(AnyURI)

AnyURI =>module_dynEnv dynEnv₁

dynEnv₁.varValue(Variable) = Value

dynEnv |-  $VarName => Value

4.1.3 Parenthesized Expressions

[89 (XQuery)]   
ParenthesizedExpr XQ
   ::=   
"(" Expr? ")"

Core Grammar

The Core grammar production for parenthesized expressions is:

[60 (Core)]   
ParenthesizedExpr
   ::=   
"(" Expr? ")"

Empty parentheses () 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

statEnv |-  () : empty

statEnv |-  Expr : Type

statEnv |-  ( Expr ) : Type

Dynamic Evaluation

Empty parentheses () evaluate to the empty sequence.

dynEnv |-  () => ()

dynEnv |-  Expr => Value

dynEnv |-  ( Expr ) => Value

4.1.4 Context Item Expression

[90 (XQuery)]   
ContextItemExpr XQ
   ::=   
"."

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 static typing rule to enforce that its value is a singleton item.

[.]Expr

==

$fs:dot

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

[93 (XQuery)]   
FunctionCall XQ
   ::=   
QName "(" (ExprSingle ("," ExprSingle)*)? ")"

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

[63 (Core)]   
FunctionCall
   ::=   
QName "(" (ExprSingle ("," ExprSingle)*)? ")"

Notation

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

[Expr]FunctionArgument(Type)

==

[[[Expr]Expr]AtomizeAtomic(Type)]Convert(Type)

where

[Expr]AtomizeAtomic(Type) denotes

If | Type <: xs:anyAtomicType*
Then | fn:data(Expr) |
Else | Expr |

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

[Expr]Convert(Type) denotes

If | Type <: xs:anyAtomicType*
Then | fs:convert-simple-operand( Expr,PrototypicalValue)
Else | Expr

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]. Also, note that in the case of built-in functions where the expected type is specified as numeric, the prototypical value is a value of type xs:double.

Normalization

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

statEnv |-  QName of func expands to expanded-QName

statEnv.typeDefn(expanded-QName) = define type QName₂ AtomicTypeDerivation

statEnv.funcType(expanded-QName,n) = declare function expanded-QName(Type₁, ..., Typen) as Type

statEnv |-  [QName (Expr₁, ..., Exprn)]Expr = QName ( [Expr₁]FunctionArgument(Type1), ..., [Exprn]FunctionArgument(Typen) )

==

QName ( [Expr₁]FunctionArgument(Type1), ..., [Exprn]FunctionArgument(Typen) )

Note that this normalization rule depends on the function signatures, which is used to get the types of the function parameters (SequenceType₁,...,SequenceTypen). 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 static typing rule, and other built-in and user-defined functions.

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

statEnv |-  QName of func expands to expanded-QName

statEnv  |-  expanded-QName() : Type

statEnv  |-  QName() : Type

statEnv |-  QName of func expands to expanded-QName

statEnv |-  Expr₁ : Type₁

...

statEnv |-  Exprn : Typen

statEnv  |-  expanded-QName(Type₁,...,Typen) : Type

statEnv  |-  QName (Expr₁,...,Exprn) : Type

The following depends on the kind of function call.

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

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

Otherwise, the following general static typing rules are applied.

The two following rules look up the function in the static environment and check 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.

statEnv.funcType(expanded-QName,0) = declare function expanded-QName() as Type'

statEnv  |-  expanded-QName() : Type'

statEnv.funcType(expanded-QName,n) = declare function expanded-QName(Type₁', ..., Typen') as Type'

statEnv  |-  Type₁ can be promoted to Type₁'

...

statEnv  |-  Typen can be promoted to Typen'

statEnv  |-  expanded-QName(Type₁, ..., Typen) : Type'

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 static typing rules which do not require access to the environment. See [C.2 Mapping of Overloaded Internal Functions].

Notation

The following auxiliary judgment

dynEnv |-  function expanded-QName with types on values yields Value

holds when applying the function with expanded QName expanded-QName and no parameter yields the value Value.

dynEnv |-  function expanded-QName with types (Type₁,...,Typen) on values (Value₁,...,Valuen) yields Value

holds when applying the function with expanded QName expanded-QName, and parameters of type (Type₁,...,Typen) on the values (Value₁,...,Valuen) 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 rules apply to all the different kinds of functions using the previously defined judgment.

statEnv |-  QName of func expands to expanded-QName

statEnv.funcType(expanded-QName) = FunctionSig

FunctionSig = declare function expanded-QName() as Type

dynEnv |-  function expanded-QName with types on values yields Value

statEnv |-  Value against Type promotes to Value'

dynEnv  |-  QName() => Value'

dynEnv |-  Expr₁ => Value₁

...

dynEnv |-  Exprn => Valuen

statEnv |-  QName of func expands to expanded-QName

statEnv.funcType(expanded-QName) = FunctionSig

FunctionSig = declare function expanded-QName(Type₁, ..., Typen) as Type

statEnv |-  Value₁ against Type₁ promotes to Value₁'

...

statEnv |-  Valuen against Typen promotes to Valuen'

dynEnv |-  function expanded-QName with types (Type₁,...,Typen) on values (Value₁',...,Valuen') yields Value

statEnv |-  Value against Type promotes to Value'

dynEnv  |-  QName ( Expr₁, ..., Exprn ) => Value'

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.

The notation AnyURI =>module_dynEnv dynEnv₁ is used to access a module context and is defined in [5.2 Module Declaration].

dynEnv.funcDefn(expanded-QName() = (Expr)

#MAIN =>module_dynEnv dynEnv₁

dynEnv₁.varValue |-  Expr => Value

dynEnv |-  function expanded-QName with types on values yields Value

dynEnv.funcDefn(expanded-QName(Type₁, ..., Typen)) = (Expr, Variable₁, ... , Variablen)

#MAIN =>module_dynEnv dynEnv₁

dynEnv₁ + varValue( Variable₁ => Value₁; ...; Variablen => Valuen)  |-  Expr => Value

dynEnv |-  function expanded-QName with types (Type₁,...,Typen) on values (Value₁,...,Valuen) yields Value

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.

dynEnv.funcDefn(expanded-QName()) = #IMPORTED(AnyURI)

AnyURI =>module_statEnv statEnv₁

AnyURI =>module_dynEnv dynEnv₁

statEnv.funcType₁(expanded-QName) = FunctionSig'

FunctionSig' = declare function expanded-QName() as Type'

dynEnv₁.funcDefn(expanded-QName() = (Expr)

dynEnv₁.varValue |-  Expr => Value

statEnv |-  Value matches Type'

dynEnv |-  function expanded-QName with types on values yields Value

dynEnv.funcDefn(expanded-QName(Type₁, ..., Typen)) = #IMPORTED(AnyURI)

AnyURI =>module_statEnv statEnv₁

AnyURI =>module_dynEnv dynEnv₁

statEnv.funcType₁(expanded-QName) = FunctionSig'

FunctionSig' = declare function expanded-QName(Type₁', ..., Typen') as Type'

statEnv |-  Value₁ matches Type₁'

...

statEnv |-  Valuen matches Typen'

dynEnv₁.funcDefn(expanded-QName(Type₁', ..., Typen')) = (Expr, Variable₁, ... , Variablen)

dynEnv₁ + varValue( Variable₁ => Value₁; ...; Variablen => Valuen)  |-  Expr => Value

statEnv |-  Value matches Type'

dynEnv |-  function expanded-QName with types (Type₁,...,Typen) on values (Value₁,...,Valuen) yields Value

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]).

dynEnv.funcDefn(expanded-QName()) = #BUILT-IN

The built-in function expanded-QName (See [Functions and Operators] or [7 Additional Semantics of Functions]) yields the value Value

dynEnv |-  function expanded-QName with types on values yields Value

dynEnv.funcDefn(expanded-QName(Type₁, ..., Typen)) = #BUILT-IN

The built-in function expanded-QName (See [Functions and Operators] or [7 Additional Semantics of Functions]) applied to values (Value₁,...,Valuen) yields the value Value

dynEnv |-  function expanded-QName with types (Type₁,...,Typen) on values (Value₁,...,Valuen) yields Value

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

dynEnv.funcDefn(expanded-QName()) = #EXTERNAL

The external function expanded-QName yields the value Value

dynEnv |-  function expanded-QName with types on values yields Value

dynEnv.funcDefn(expanded-QName(Type₁, ..., Typen)) = #EXTERNAL

The external function expanded-QName applied to values (Value₁,...,Valuen) yields the value Value

dynEnv |-  function expanded-QName with types (Type₁,...,Typen) on values (Value₁,...,Valuen) yields Value

4.2 Path Expressions

Introduction

Path expressions are used to locate nodes within a tree. There are two kinds of path expressions, absolute path expressions and relative path expressions. An absolute path expression is a rooted relative path expression. A relative path expression is composed of a sequence of steps.

Path Expressions

[68 (XQuery)]   
PathExpr XQ
   ::=   
("/" RelativePathExpr?)
| ("//" RelativePathExpr)
| RelativePathExpr

[69 (XQuery)]   
RelativePathExpr XQ
   ::=   
StepExpr (("/" | "//") StepExpr)*

Core Grammar

PathExpr and RelativePathExpr are fully normalized, therefore they have no corresponding productions in the Core. The grammar for path expressions in the Core starts with the StepExpr production.

Normalization

Absolute path expressions are path expressions starting with the / or // symbols, indicating that the expression must be applied on the root node in the current context. The root node in the current context is the greatest ancestor of the context node. The following two rules normalize absolute path expressions to relative ones. They use the fn:root function, which returns the greatest ancestor of its argument node. The treat expressions guarantee that the value bound to the context variable $fs:dot is a document node.

[/]Expr

==

[(fn:root(self::node()) treat as document-node())]Expr

[/ RelativePathExpr]Expr

==

[((fn:root(self::node())) treat as document-node()) / RelativePathExpr]Expr

[// RelativePathExpr]Expr

==

[((fn:root(self::node())) treat as document-node()) / descendant-or-self::node() / RelativePathExpr]Expr

[RelativePathExpr // StepExpr ]Expr

==

[RelativePathExpr / descendant-or-self::node() / StepExpr]Expr

A composite relative path expression (using /) is normalized into a for expression by concatenating the sequences obtained by mapping each node of the left-hand side in document order to the sequence it generates on the right-hand side. The call to the fs:distinct-doc-order function ensures that the result is in document order without duplicates. The dynamic context is defined by binding the $fs:dot, $fs:sequence, $fs:position and $fs:last variables.

Note that sorting by document order enforces the restriction that input and output sequences contains only nodes, and that the last step in a path expression may actually return atomic values.

[RelativePathExpr / StepExpr]Expr

==

fs:apply-ordering-mode (

fs:distinct-doc-order-or-atomic-sequence (

  let $fs:sequence as node()* := [RelativePathExpr]Expr return

  let $fs:last := fn:count($fs:sequence) return

  for $fs:dot at $fs:position in $fs:sequence return

    [StepExpr]Expr

))

4.2.1 Steps

Note that this section uses some auxiliary judgments which are defined in [8.2 Judgments for step expressions and filtering].

Introduction

Steps

[70 (XQuery)]    | StepExpr XQ |    ::=    | FilterExpr | AxisStep
[71 (XQuery)]    | AxisStep XQ |    ::=    | (ReverseStep | ForwardStep) PredicateList
[72 (XQuery)]    | ForwardStep XQ |    ::=    | (ForwardAxis NodeTest) | AbbrevForwardStep
[75 (XQuery)]    | ReverseStep XQ |    ::=    | (ReverseAxis NodeTest) | AbbrevReverseStep
[82 (XQuery)]    | PredicateList XQ |    ::=    | Predicate*

Core Grammar

The Core grammar productions for XPath steps are:

Steps

[46 (Core)]    | StepExpr |    ::=    | PrimaryExpr | AxisStep
[47 (Core)]    | AxisStep |    ::=    | ReverseStep | ForwardStep
[48 (Core)]    | ForwardStep |    ::=    | ForwardAxis NodeTest
[50 (Core)]    | ReverseStep |    ::=    | ReverseAxis NodeTest

Note

Step expressions can be followed by predicates. Normalization of predicates uses the following auxiliary mapping rule: []Predicates, which is specified in [4.2.2 Predicates]. Normalization for step expressions also uses the following auxiliary mapping rule: []Axis, which is specified in [4.2.1.1 Axes].

Normalization

Normalization of predicates need to distinguish between forward steps, reverse steps, and primary expressions.

As explained in the [XPath/XQuery] document, applying a step in XPath changes the focus (or context). The change of focus is made explicit by the normalization rule below, which binds the variable $fs:dot to the node currently being processed, and the variable $fs:position to the position (i.e., the position within the input sequence) of that node.

There are two sets of normalization rules for Predicates. The first set of rules apply when the predicate is a numeric literal or the expression last(). The second set of rules apply to all predicate expressions other than numeric literals and the expression last(). In the first case, the normalization rules provides a more precise static type than if the general rules were applied.

When the predicate expression is a numeric literal or the fn:last function, the following normalization rules apply.

[ForwardStep PredicateList [ NumericLiteral ]]Expr

==

let $fs:sequence := fs:apply-ordering-mode( fs:distinct-doc-order( [ForwardStep PredicateList]Expr )) return

fn:subsequence($fs:sequence, NumericLiteral,1)

[ForwardStep PredicateList [ fn:last() ]]Expr

==

let $fs:sequence := fs:apply-ordering-mode( fs:distinct-doc-order( [ForwardStep PredicateList]Expr )) return

let $fs:last := fn:count($fs:sequence) return

fn:subsequence($fs:sequence, $fs:last,1)

When predicates are applied on a reverse step, the position variable is bound in reverse document order.

[ReverseStep PredicateList [ NumericLiteral ]]Expr

==

let $fs:sequence := fs:apply-ordering-mode( fs:distinct-doc-order( [ReverseStep PredicateList]Expr )) return

let $fs:last := fn:count($fs:sequence) return

let $fs:position := fs:plus(1, fs:minus($fs:last, NumericLiteral)) return

  fn:subsequence($fs: sequence,$fs:position,1)

When the step is a reverse axis, then the last item in the context sequence is the first in document order.

[ReverseStep PredicateList [ fn:last() ]]Expr

==

let $fs:sequence := fs:apply-ordering-mode( fs:distinct-doc-order( [ReverseStep PredicateList]Expr )) return

  fn:subsequence($fs: sequence,1,1)

The normalization rules above all use the function fn:subsequence to select a particular item. The static typing rules for this function are defined in [7.2.13 The fn:subsequence function].

When predicates are applied on a forward step, the input sequence is first sorted in document order and duplicates are removed. The context is changed by binding the $fs:dot variable to each node in document order.

[ForwardStep PredicateList [ Expr ]]Expr

==

let $fs:sequence := fs:apply-ordering-mode( fs:distinct-doc-order( [ForwardStep PredicateList]Expr )) return

let $fs:last := fn:count($fs:sequence) return

for $fs:dot at $fs:position in $fs:sequence return

   if ([Expr]Predicates) then $fs:dot else ()

When predicates are applied on a reverse step, the input sequence is first sorted in document order and duplicates are removed. The context is changed by binding the $fs:dot variable to each node in document order.

[ReverseStep PredicateList [ Expr ]]Expr

==

let $fs:sequence := fs:apply-ordering-mode( fs:distinct-doc-order( [ReverseStep PredicateList]Expr )) return

let $fs:last := fn:count($fs:sequence) return

for $fs:dot at $fs:new in $fs:sequence return

let $fs:position := fs:plus(1,fs:minus( $fs:last,$fs:new)) return

  if ([Expr]Predicates) then $fs:dot else ()

Finally, a stand-alone forward or reverse step is normalized by the auxiliary normalization rule for Axis.

[ForwardStep]Expr

==

fs:apply-ordering-mode( [ForwardStep]Axis)

[ReverseStep]Expr

==

fs:apply-ordering-mode( [ReverseStep]Axis)

Static Type Analysis

The static semantics of an Axis NodeTest pair is obtained by retrieving the type of the context node, and applying the two filters (the Axis, and then the NodeTest with a PrincipalNodeKind) on the result.

statEnv.varType((FS-URI,"dot")) = Type₁

statEnv  |-  Type₁ <: [node()]sequencetype

statEnv |-  axis Axis of Type₁ : Type₂

Axis has principal PrincipalNodeKind

statEnv |-  test NodeTest with PrincipalNodeKind of Type₂ : Type₃

statEnv |-  Axis NodeTest : Type₃

Note

Note that the second judgment in the rule requires that the context item be a node, guaranteeing that a type error is raised when the context item is an atomic value.

Dynamic Evaluation

The dynamic semantics of an Axis NodeTest pair is obtained by retrieving the context node, and applying the two filters (Axis, then NodeTest) on the result. The application of each filter is expressed through several auxiliary judgments (of, has principal, and test), as follows.

dynEnv.varValue($fs:dot) = Value₁

statEnv  |-  Value₁ matches [node()]sequencetype

dynEnv |-  axis Axis of Value₁ => Value₂

Axis has principal PrincipalNodeKind

dynEnv |-  test NodeTest with PrincipalNodeKind of Value₂ => Value₃

dynEnv |-  Axis NodeTest => fs:distinct-doc-order( Value₃)

Note

Note that the second judgment in the rule guarantees that the context item is bound to a node.

4.2.1.1 Axes

Introduction

The XQuery grammar for forward and reverse axis is as follows.

Axes

[73 (XQuery)]   
ForwardAxis XQ
   ::=   
("child" "::")
| ("descendant" "::")
| ("attribute" "::")
| ("self" "::")
| ("descendant-or-self" "::")
| ("following-sibling" "::")
| ("following" "::")

[76 (XQuery)]   
ReverseAxis XQ
   ::=   
("parent" "::")
| ("ancestor" "::")
| ("preceding-sibling" "::")
| ("preceding" "::")
| ("ancestor-or-self" "::")

In the case of XPath, forward axis also contain the namespace:: axis.

Axes

[30 (XPath)]   
ForwardAxis XP
   ::=   
("child" "::")
| ("descendant" "::")
| ("attribute" "::")
| ("self" "::")
| ("descendant-or-self" "::")
| ("following-sibling" "::")
| ("following" "::")
| ("namespace" "::")

Core Grammar

The Core grammar productions for XPath axis are:

Axes

[49 (Core)]   
ForwardAxis
   ::=   
("child" "::")
| ("descendant" "::")
| ("attribute" "::")
| ("self" "::")
| ("descendant-or-self" "::")
| ("namespace" "::")

[51 (Core)]   
ReverseAxis
   ::=   
("parent" "::")
| ("ancestor" "::")
| ("ancestor-or-self" "::")

Notation

We introduce the following auxiliary grammar production to describe all axis.

[90 (Formal)]   
Axis
   ::=   
ForwardAxis | ReverseAxis

Notation

The normalization of axes uses the following auxiliary mapping rule: []Axis.

Normalization

The normalization for all axes is specified as follows.

The semantics of the following(-sibling) and preceding(-sibling) axes are expressed by mapping them to Core expressions. All other axes are part of the Core and therefore are left unchanged through normalization.

[following-sibling:: NodeTest]Axis

==

[let $e := . return $e/parent::node()/child:: NodeTest [.>>$e]]Expr

[following:: NodeTest]Axis

==

[ancestor-or-self::node()/following-sibling::node()/descendant-or-self:: NodeTest]Expr

All other forward axes are part of the Core [XPath/XQuery] and handled by the normalization rules below:

[child:: NodeTest]Axis

==

child:: NodeTest

[attribute:: NodeTest]Axis

==

attribute:: NodeTest

[self:: NodeTest]Axis

==

self:: NodeTest

[descendant:: NodeTest]Axis

==

descendant:: NodeTest

[descendant-or-self:: NodeTest]Axis

==

descendant-or-self:: NodeTest

[namespace:: NodeTest]Axis

==

namespace:: NodeTest

Reverse axes:

[preceding-sibling:: NodeTest]Axis

==

[let $e := . return $e/parent::node()/child:: NodeTest [.<<$e]]Expr

[preceding:: NodeTest]Axis

==

[ancestor-or-self::node()/preceding-sibling::node()/descendant-or-self:: NodeTest]Expr

All other reverse axes are part of the Core [XPath/XQuery] and handled by the normalization rules below:

[parent:: NodeTest]Axis

==

parent:: NodeTest

[ancestor:: NodeTest]Axis

==

ancestor:: NodeTest

[ancestor-or-self:: NodeTest]Axis

==

ancestor-or-self:: NodeTest

4.2.1.2 Node Tests

Introduction

A node test is a condition applied on the nodes selected by an axis step. Node tests are described by the following grammar productions.

Node Tests

[78 (XQuery)]   
NodeTest XQ
   ::=   
KindTest | NameTest

[79 (XQuery)]   
NameTest XQ
   ::=   
QName | Wildcard

[80 (XQuery)]   
Wildcard XQ
   ::=   
"*"
| (NCName ":" "*")
| ("*" ":" NCName)

Core Grammar

The Core grammar productions for node tests are:

Node Tests

[52 (Core)]   
NodeTest
   ::=   
KindTest | NameTest

[53 (Core)]   
NameTest
   ::=   
QName | Wildcard

[54 (Core)]   
Wildcard
   ::=   
"*"
| (NCName ":" "*")
| ("*" ":" NCName)

Notation

For convenience, we will use the grammar non-terminals Prefix, and LocalPart, both of which are NCNames, in some of the inference rules. They are defined by the following grammar productions.

Prefix and LocalPart

[18 (Formal)]    | Prefix |    ::=    | NCName
[19 (Formal)]    | LocalPart |    ::=    | NCName

4.2.2 Predicates

Introduction

A predicate consists of an expression, called a predicate expression, enclosed in square brackets.

[83 (XQuery)]   
Predicate XQ
   ::=   
"[" Expr "]"

Notation

Normalization of predicates uses the following auxiliary mapping rule: []Predicates.

Normalization

Predicates in path expressions are normalized with a special mapping rule:

[Expr]Predicates

==

typeswitch ([Expr]Expr)

  case $v as fs:numeric return op:numeric-equal($v, $fs:position)

  default $v return fn:boolean($v)

Note that the semantics of predicates whose input expression returns a numeric value also work if that value is not an integer. In those cases the op:numeric-equal returns false when compared to a position. For example, the expression //a[3.4] always returns the empty sequence.

4.2.3 Unabbreviated Syntax

The corresponding Section in the [XPath/XQuery] document just contains examples.

4.2.4 Abbreviated Syntax

Abbreviated Syntax

[74 (XQuery)]    | AbbrevForwardStep XQ |    ::=    | "@"? NodeTest
[77 (XQuery)]    | AbbrevReverseStep XQ |    ::=    | ".."

Normalization

Here are normalization rules for the abbreviated syntax.

[..]Axis

==

parent::node()

[@NodeTest]Axis

==

attribute::NodeTest

[NodeTest]Axis

==

child::NodeTest

4.3 Sequence Expressions

Introduction

[XPath/XQuery] supports operators to construct and combine sequences. A sequence is an ordered collection of zero or more items. An item is either an atomic value or a node.

4.3.1 Constructing Sequences

Constructing Sequences

[31 (XQuery)]    | Expr XQ |    ::=    | ExprSingle ("," ExprSingle)*
[49 (XQuery)]    | RangeExpr XQ |    ::=    | AdditiveExpr ( "to" AdditiveExpr )?

Core Grammar

The Core grammar production for sequence expressions is:

Core Sequence Expressions

[22 (Core)]   
Expr
   ::=   
ExprSingle ("," ExprSingle)*

Normalization

A sequence expression is normalized into a sequence of normalized single expressions:

[Expr₁ , Expr₂]Expr

==

[Expr₁]Expr, [Expr₂]Expr

Static Type Analysis

The type of the sequence expression is the sequence over the types of the individual expressions.

statEnv  |-  Expr₁ : Type₁      statEnv  |-  Expr₂ : Type₂

statEnv  |-  Expr₁ , Expr₂ : Type₁, Type₂

Dynamic Evaluation

Each expression in the sequence is evaluated and the resulting values are concatenated into one sequence.

dynEnv |-  Expr₁ => Value₁     dynEnv |-  Expr₂ => Value₂

dynEnv |-  Expr₁, Expr₂ => Value₁, Value₂

Normalization

The range operator is normalized to the fs:to function.

[Expr₁ to Expr₂]Expr

==

fs:to(([Expr₁]Expr),([Expr₂]Expr))

Static Type Analysis

The static semantics of the fs:to function is defined in [7.1.12 The fs:to function].

Dynamic Evaluation

The dynamic semantics of the fs:to function is defined in [7.1.12 The fs:to function].

4.3.2 Filter Expressions

Introduction

Filter Expression

[81 (XQuery)]   
FilterExpr XQ
   ::=   
PrimaryExpr PredicateList

Core Grammar

There are no Core grammar productions for filter expressions as they are normalized to other Core expressions.

Normalization

When a predicate with a numeric literal or the last() expression is applied on a primary expression, it is normalized using the fn:subsequence function. This results in a more precise static type for those cases.

[PrimaryExpr PredicateList [ NumericLiteral ]]Expr

==

let $fs:sequence := [PrimaryExpr PredicateList]Expr return

fn:subsequence($fs:sequence, NumericLiteral,1)

[PrimaryExpr PredicateList [ fn:last() ]]Expr

==

let $fs:sequence := [PrimaryExpr PredicateList]Expr return

fn:subsequence($fs:sequence, $fs:last,1)

In the general case, when a predicate is applied on a primary expression, it is normalized to a FLWOR expression as follows. The input sequence is processed in sequence order and the context item is bound to each item in the input sequence.

[PrimaryExpr PredicateList [ Expr ]]Expr

==

let $fs:sequence := [PrimaryExpr PredicateList]Expr return

let $fs:last := fn:count($fs:sequence) return

for $fs:dot at $fs:position in $fs:sequence return

   if ([Expr]Predicates) then $fs:dot else ()

Static Type Analysis

There are no additional static typing rules for filter expressions.

Dynamic Evaluation

There are no additional dynamic evaluation rules for filter expressions.

4.3.3 Combining Node Sequences

[XPath/XQuery] provides several operators for combining sequences of nodes.

Combining Sequences

[52 (XQuery)]    | UnionExpr XQ |    ::=    | IntersectExceptExpr ( ("union" | "|") IntersectExceptExpr )*
[53 (XQuery)]    | IntersectExceptExpr XQ |    ::=    | InstanceofExpr ( ("intersect" | "except") InstanceofExpr )*

Notation

The union, intersect, and except expressions are normalized into function calls to the appropriate functions. The mapping function []SequenceOp is defined by the following table:

SequenceOp | [SequenceOp]SequenceOp
"union" | op:union
"|" | op:union
"intersect" | op:intersect
"except" | op:except

Normalization

Operators for combining node sequences are normalized as follows.

[Expr₁ SequenceOp Expr₂]Expr

==

fs:apply-ordering-mode ([SequenceOp]SequenceOp ( [Expr₁]Expr, [Expr₂]Expr ))

Static Type Analysis

The static semantics of the operators that combine sequences are defined in [7.2.14 The op:union, op:intersect, and op:except operators].

Dynamic Evaluation

The dynamic semantics for function calls is given in [4.1.5 Function Calls].

4.4 Arithmetic Expressions

[XPath/XQuery] provides arithmetic operators for addition, subtraction, multiplication, division, and modulus, in their usual binary and unary forms.

Arithmetic Expressions

[50 (XQuery)]    | AdditiveExpr XQ |    ::=    | MultiplicativeExpr ( ("+" | "-") MultiplicativeExpr )*
[51 (XQuery)]    | MultiplicativeExpr XQ |    ::=    | UnionExpr ( ("*" | "div" | "idiv" | "mod") UnionExpr )*
[58 (XQuery)]    | UnaryExpr XQ |    ::=    | ("-" | "+")* ValueExpr
[59 (XQuery)]    | ValueExpr XQ |    ::=    | ValidateExpr | PathExpr | ExtensionExpr

Core Grammar

The Core grammar production for arithmetic expressions is:

[40 (Core)]   
ValueExpr
   ::=   
ValidateExpr | StepExpr | ExtensionExpr

Notation

The mapping function []ArithOp is defined by the following table:

ArithOp | [ArithOp]ArithOp
"+" | fs:plus
"-" | fs:minus
"*" | fs:times
"div" | fs:div
"mod" | fs:mod

Core Grammar

There are no Core grammar productions for arithmetic expressions as they are normalized to other Core expressions.

Normalization

The normalization rules for all the arithmetic operators except idiv first atomize each argument by applying fn:data and then apply the internal function fs:convert-operand to each argument. If the first argument to this function has type xs:untypedAtomic, then the first argument is cast to a double, otherwise it is returned unchanged. The overloaded internal function corresponding to the arithmetic operator is then applied to the two converted arguments. The table above maps the operators to the corresponding internal function. The mapping from the overloaded internal functions to the corresponding non-overloaded function is given in [C.2 Mapping of Overloaded Internal Functions].

[Expr₁ ArithOp Expr₂]Expr

==

[ArithOp]ArithOp (
fs:convert-operand( fn:data(([Expr₁ ]Expr)), 1.0E0),

fs:convert-operand( fn:data(([Expr₂ ]Expr)), 1.0E0))

The normalization rules for the idiv operator are similar, but instead of casting arguments with type xs:untypedAtomic to xs:double, they are cast to xs:integer.

[Expr₁ idiv Expr₂]Expr

==

fs:idiv (
fs:convert-operand( fn:data(([Expr₁ ]Expr)), 1),

fs:convert-operand( fn:data(([Expr₂ ]Expr)), 1))

The unary operators are mapped similarly.

[+ Expr]Expr

==

fs:unary-plus(fs:convert-operand( fn:data(([Expr]Expr)), 1.0E0))

[- Expr]Expr

==

fs:unary-minus(fs:convert-operand( fn:data(([Expr]Expr)), 1.0E0))

Static Type Analysis

The static semantics for function calls is given in [4.1.5 Function Calls]. The mapping from the overloaded internal functions to the corresponding non-overloaded function is given in [C.2 Mapping of Overloaded Internal Functions].

Dynamic Evaluation

The dynamic semantics for function calls is given in [4.1.5 Function Calls]. The mapping from the overloaded internal functions to the corresponding non-overloaded function is given in [C.2 Mapping of Overloaded Internal Functions].

4.5 Comparison Expressions

Introduction

Comparison expressions allow two values to be compared. [XPath/XQuery] provides three kinds of comparison expressions, called value comparisons, general comparisons, and node comparisons.

Comparison Expressions

[48 (XQuery)]   
ComparisonExpr XQ
   ::=   
RangeExpr ( (ValueComp
| GeneralComp
| NodeComp) RangeExpr )?

[61 (XQuery)]   
ValueComp XQ
   ::=   
"eq" | "ne" | "lt" | "le" | "gt" | "ge"

[60 (XQuery)]   
GeneralComp XQ
   ::=   
"=" | "!=" | "<" | "<=" | ">" | ">="

[62 (XQuery)]   
NodeComp XQ
   ::=   
"is" | "<<" | ">>"

4.5.1 Value Comparisons

Notation

The mapping function []ValueComp is defined by the following table:

ValueComp | [ValueComp]ValueComp
"eq" | fs:eq
"ne" | fs:ne
"lt" | fs:lt
"le" | fs:le
"gt" | fs:gt
"ge" | fs:ge

Core Grammar

There are no Core grammar productions for value comparisons as they are normalized to other Core expressions.

Normalization

The normalization rules for the value comparison operators first atomize each argument by applying fn:data and then apply the internal function fs:convert-operand defined in [7.1.1 The fs:convert-operand function]. If the first argument to this function has type xs:untypedAtomic, then the first argument is cast to a string, otherwise it is returned unchanged. The overloaded internal function corresponding to the value comparison operator is then applied to the two converted arguments. The table above maps the value operators to the corresponding internal function. The mapping from the overloaded internal functions to the corresponding non-overloaded function is given in [C.2 Mapping of Overloaded Internal Functions].

[Expr₁ ValueComp Expr₂]Expr

==

[ValueComp]ValueComp (
fs:convert-operand( fn:data(([Expr₁ ]Expr)), "string"),

fs:convert-operand( fn:data(([Expr₂ ]Expr)), "string") )

Static Type Analysis

The static semantics for function calls is given in [4.1.5 Function Calls]. The comparison functions all have return type xs:boolean, as specified in [Functions and Operators].

Dynamic Evaluation

The dynamic semantics for function calls is given in [4.1.5 Function Calls].

4.5.2 General Comparisons

Introduction

General comparisons are defined by adding existential semantics to value comparisons. The operands of a general comparison may be sequences of any length. The result of a general comparison is always true or false.

Notation

The function []GeneralComp is defined by the following table:

GeneralComp | [GeneralComp]GeneralComp
"=" | fs:eq
"!=" | fs:ne
"<" | fs:lt
"<=" | fs:le
">" | fs:gt
">=" | fs:ge

Core Grammar

There are no Core grammar productions for general comparisons as they are normalized to existentially quantified Core expressions.

Normalization

The normalization rule for a general comparison expression first atomizes each argument by applying fn:data and then applies the existentially quantified SomeExpr expression to each sequence. The internal function fs:convert-operand is applied to each pair of atomic values. If the first argument to this function has type xs:untypedAtomic, then the first argument is cast to type of the second argument. If the second argument has type xs:untypedAtomic, the first argument is cast to a string. The overloaded internal function corresponding to the general comparison operator is then applied to the two converted values.

[Expr₁ GeneralComp Expr₂]Expr

==

some $v1 in fn:data(([Expr₁]Expr)) satisfies

some $v2 in fn:data(([Expr₂]Expr)) satisfies

let $u1 := fs:convert-operand($v1, $v2) return

let $u2 := fs:convert-operand($v2, $v1) return

[GeneralComp]GeneralComp ($u1, $u2)

4.5.3 Node Comparisons

Core Grammar

There are no Core grammar productions for node comparisons as they are normalized to other Core expressions.

Normalization

The normalization rules for node comparisons map each argument expression and then apply the internal function corresponding to the node comparison operator. The internal function are defined in [C.2 Mapping of Overloaded Internal Functions].

[Expr₁ is Expr₂]Expr

==

   fs:is-same-node(([Expr₁]Expr), ([Expr₂]Expr))

[Expr₁ << Expr₂]Expr

==

fs:node-before(([Expr₁]Expr), ([Expr₂]Expr))

[Expr₁ >> Expr₂]Expr

==

fs:node-after(([Expr₁]Expr), ([Expr₂]Expr))

Static Type Analysis

The static semantics for the internal functions are defined in [C.2 Mapping of Overloaded Internal Functions].

Dynamic Evaluation

The dynamic semantics for internal function is defined in [C.2 Mapping of Overloaded Internal Functions].

4.6 Logical Expressions

Introduction

A logical expression is either an and-expression or an or-expression. The value of a logical expression is always one of the boolean values: true or false.

Logical Expressions

[46 (XQuery)]    | OrExpr XQ |    ::=    | AndExpr ( "or" AndExpr )*
[47 (XQuery)]    | AndExpr XQ |    ::=    | ComparisonExpr ( "and" ComparisonExpr )*

Core Grammar

The Core grammar productions for logical expressions are:

Core Logical Expressions

[36 (Core)]    | OrExpr |    ::=    | AndExpr ( "or" AndExpr )*
[37 (Core)]    | AndExpr |    ::=    | CastableExpr ( "and" CastableExpr )*

Normalization

The normalization rules for "and" and "or" first get the effective boolean value of each argument, then apply the appropriate Core operator.

[Expr₁ and Expr₂]Expr

==

fn:boolean(([Expr₁]Expr)) and fn:boolean(([Expr₂]Expr))

[Expr₁ or Expr₂]Expr

==

fn:boolean(([Expr₁]Expr)) or fn:boolean(([Expr₂]Expr))

Static Type Analysis

The logical expressions require that each subexpression have type xs:boolean. The result type is also xs:boolean.

statEnv  |-  Expr₁ : xs:boolean      statEnv  |-  Exprn : xs:boolean

statEnv  |-  Expr₁ and Expr₂ : xs:boolean

statEnv  |-  Expr₁ : xs:boolean      statEnv  |-  Exprn : xs:boolean

statEnv  |-  Expr₁ or Expr₂ : xs:boolean

Dynamic Evaluation

The dynamic semantics of logical expressions is non-deterministic. This non-determinism permits implementations to use short-circuit evaluation strategies when evaluating logical expressions. In the expression, Expr₁ and Expr₂, if either expression raises an error or evaluates to false, the entire expression may raise an error or evaluate to false. In the expression, Expr₁ or Expr₂, if either expression raises an error or evaluates to true, the entire expression may raise an error or evaluate to true.

dynEnv  |-  Expri => false

i in { 1,2 }

dynEnv  |-  Expr₁ and Expr₂ => false

dynEnv  |-  Expr₁ => true      dynEnv  |-  Expr₂ => true

dynEnv  |-  Expr₁ and Expr₂ => true

dynEnv  |-  Expri => true

i in { 1,2 }

dynEnv  |-  Expr₁ or Expr₂ => true

dynEnv  |-  Expr₁ => false      dynEnv  |-  Expr₂ => false

dynEnv  |-  Expr₁ or Expr₂ => false

4.7 Constructors

[XPath/XQuery] supports two forms of constructors. Direct constructors support literal XML syntax for elements, attributes, text nodes, processing-instructions and comments. Computed constructors can be used to construct elements, attributes, text nodes, processing-instructions, comments, and document nodes. All direct constructors are normalized into computed constructors, i.e., there are no direct-constructor expressions in the Core.

Constructors

[94 (XQuery)]   
Constructor XQ
   ::=   
DirectConstructor
| ComputedConstructor

[95 (XQuery)]   
DirectConstructor XQ
   ::=   
DirElemConstructor
| DirCommentConstructor
| DirPIConstructor

[96 (XQuery)]   
DirElemConstructor XQ
   ::=   
"<" QName DirAttributeList ("/>" | (">" DirElemContent* "</" QName S? ">"))

[101 (XQuery)]   
DirElemContent XQ
   ::=   
DirectConstructor
| CDataSection
| CommonContent
| ElementContentChar

[148 (XQuery)]   
ElementContentChar XQ
   ::=   
Char - [{}<&]

[102 (XQuery)]   
CommonContent XQ
   ::=   
PredefinedEntityRef | CharRef | "{{" | "}}" | EnclosedExpr

[107 (XQuery)]   
CDataSection XQ
   ::=   
"<![CDATA[" CDataSectionContents "]]>"

[108 (XQuery)]   
CDataSectionContents XQ
   ::=   
(Char* - (Char* ']]>' Char*))

[97 (XQuery)]   
DirAttributeList XQ
   ::=   
(S (QName S? "=" S? DirAttributeValue)?)*

[98 (XQuery)]   
DirAttributeValue XQ
   ::=   
('"' (EscapeQuot | QuotAttrValueContent)* '"')
| ("'" (EscapeApos | AposAttrValueContent)* "'")

[99 (XQuery)]   
QuotAttrValueContent XQ
   ::=   
QuotAttrContentChar
| CommonContent

[100 (XQuery)]   
AposAttrValueContent XQ
   ::=   
AposAttrContentChar
| CommonContent

[149 (XQuery)]   
QuotAttrContentChar XQ
   ::=   
Char - ["{}<&]

[150 (XQuery)]   
AposAttrContentChar XQ
   ::=   
Char - ['{}<&]

[146 (XQuery)]   
EscapeQuot XQ
   ::=   
'""'

[147 (XQuery)]   
EscapeApos XQ
   ::=   
"''"

[29 (XQuery)]   
EnclosedExpr XQ
   ::=   
"{" Expr "}"

Core Grammar

The Core grammar productions for constructors are:

Constructors

[64 (Core)]   
Constructor
   ::=   
ComputedConstructor

[65 (Core)]   
ComputedConstructor
   ::=   
CompDocConstructor
| CompElemConstructor
| CompAttrConstructor
| CompTextConstructor
| CompCommentConstructor
| CompPIConstructor

[21 (Core)]   
EnclosedExpr
   ::=   
"{" Expr "}"

There are no Core grammar productions for direct XML element or attribute constructors as they are normalized to computed constructors.

4.7.1 Direct Element Constructors

Introduction

The static and dynamic semantics of the direct forms of element and attribute constructors are specified on the equivalent computed element and attribute constructors.

Notation

The auxiliary mapping rules []ElementContent, []ElementContentUnit, []PartitionIntoUnits, and []DirCharsUnits are defined in this section and are used for the normalization of the content of direct element constructors.

Notation

An element-content unit is either a maximal contiguous sequence of literal characters (including character references, escaped braces, and predefined entity references), an enclosed expression, a direct element constructor, an XML comment, or an XML processing instruction. We use the following auxiliary grammar productions to describe element-content units.

[83 (Formal)]    | ElementContentUnit |    ::=    | DirectConstructor | EnclosedExpr | DirCharsUnit
[84 (Formal)]    | DirCharsUnit |    ::=    | (CDataSection | PredefinedEntityRef | CharRef | "{{" | "}}" | ElementContentChar)+

We use the auxiliary normalization rule [ DirElemContent* ]PartitionIntoUnits to restructure the original element content, DirElemContent*, into the appropriate sequence of element-content units. This normalization rule is not specified formally.

Here are three direct element constructors, each of which contains one element-content unit:

<date>{ xs:date("2003-03-18") }</date>

<name>Dizzy Gillespie</name>

<comment><!-- Just a comment --></comment>

The first contains one enclosed expression, the second contains one contiguous sequence of characters, and the third contains one XML comment.

After boundary whitespace is stripped, the next example contains six element-content units:

<address>
  <!-- Dizzy's address -->
  { 123 }-0A <street>Roosevelt Ave.</street> Flushing, NY { 11368 }
</address>

It contains an XML comment, followed by an enclosed expression that contains the integer 123, a contiguous sequence of characters ("-0A "), a direct XML element constructor, a contiguous sequence of characters (" Flushing, NY "), and an enclosed expression that contains the integer 11368. Evaluation of that constructor will result in the following element.

<address><!-- Dizzy's address -->123-0A <street>Roosevelt Ave.</street> Flushing, NY 11368</address>

Normalization

We start by giving the rules for the two forms of direct XML element constructors. Note that the direct attribute constructors are normalized twice: the []NamespaceAttrs normalizes the namespace-declaration attributes and []Attribute normalizes all other attributes that are not namespace-declaration attributes.

[ < QName DirAttributeList > DirElemContent* </ QName S? > ]Expr

==

element QName { [ DirAttributeList ]Attribute , [ [ DirElemContent* ]PartitionIntoUnits ]ElementContent } { [ DirAttributeList ]NamespaceAttrs }

[ < QName DirAttributeList /> ]Expr

==

element QName { [ DirAttributeList ]Attribute } { [ DirAttributeList ]NamespaceAttrs }

We can now give the rules for normalizing a direct element constructor's content. We distinguish between direct element constructors that contain only one element-content unit and those that contain more than one element-content unit.

Adjacent element-content units are convenient because they permit arbitrary interleaving of text and atomic data. During evaluation, atomic values are converted to text nodes containing the string representations of the atomic values, and then adjacent text nodes are concatenated together. In the example at the beginning of this section, the integer 123 is converted to a string and concatenated with "-0A" and the result is a single text node containing "123-0A".

Below are two examples of normalization for element constructors.

<date>{ xs:date("2003-03-18") }</date>
 =
element date {
  fs:item-sequence-to-node-sequence(
    xs:date("2003-03-18")
  )
}

<address>
  <!-- Dizzy's address -->
  { 123 }-0A <street>Roosevelt Ave.</street> Flushing, NY { 11368 }
</address>
 =
element address {
  fs:item-sequence-to-node-sequence(
    comment { " Dizzy's address "},
    123,
    text { "-0A "},
    element street {"Roosevelt Ave."},
    text { " Flushing, NY "  },
    11368
  )
}

We normalize each unit individually and construct a sequence of the normalized results interleaved with empty text nodes. The empty text nodes guarantee that the results of evaluating consecutive element-content units can be distinguished. Then we apply the function fs:item-sequence-to-node-sequence. Section 3.7.1 Direct Element ConstructorsXQ specifies the rules for converting a sequence of atomic values and nodes into a sequence of nodes before element construction. The Formal Semantics function fs:item-sequence-to-node-sequence implements these conversion rules.

[ElementContentUnit 1]ElementContent

==

fs:item-sequence-to-node-sequence(( [ ElementContentUnit 1]ElementContentUnit))

[ElementContentUnit 1, ..., ElementContentUnit n]ElementContent

==

fs:item-sequence-to-node-sequence(( [ ElementContentUnit 1 ]ElementContentUnit , text { "" }, ..., text { "" }, [ ElementContentUnit n]ElementContentUnit))

We must distinguish between the results of consecutive element-content units, because the rule for converting sequences of atomic values into strings applies to sequences within distinct enclosed expressions. The empty text nodes are eliminated during evaluation of fs:item-sequence-to-node-sequence when consecutive text nodes are coalesced into a single text node. The text node guarantees that a whitespace character will not be inserted between atomic values computed by distinct enclosed expressions. For example, here is an expression, its normalization, and the resulting XML value:

<example>{ 1 }{ 2 }</example>
 =
element example { fs:item-sequence-to-node-sequence ((1, text {""}, 2)) }
 ==>
<example>12</example>

In the absence of the empty text node, the expression would evaluate to the following incorrect value:

<example>{ 1 }{ 2 }</example>
 (incorrect normalization) =
element example { fs:item-sequence-to-node-sequence ((1, 2)) }
 (incorrect value) ==>
<example>1 2</example>

Next, we give the normalization rules for each element-content unit. The normalization rule for a contiguous sequence of characters assumes that the significant whitespace characters in element constructors have been preserved, as described in [4.7.1.4 Boundary Whitespace].

The following normalization rule takes the longest consecutive sequence of individual characters that include literal characters, escaped curly braces, character references, and predefined entity references and normalizes the character sequence as a text node containing the string of characters.

[DirCharsUnit]ElementContentUnit

==

text { [ DirCharsUnit ]DirCharsUnits }

The application of []DirCharsUnits to DirCharsUnit is defined informally. It produces a string literal corresponding to the content of the DirCharsUnit, in boundary whitespace is processed and non-literal characters (CharRefs, PredefinedEntityRefs, CDataSections, and escaped-braces) are resolved according to the rules in Section 3.7.1.3 ContentXQ.

XML processing instructions and comments in element content are normalized by applying the standard normalization rules for expressions, which appear in [4.7.2 Other Direct Constructors].

[DirPIConstructor]ElementContentUnit

==

[DirPIConstructor]Expr

[DirCommentConstructor]ElementContentUnit

==

[DirCommentConstructor]Expr

A direct element constructor is normalized using the normalization rule for expressions.

[DirElemConstructor]ElementContentUnit

==

[DirElemConstructor]Expr

An enclosed expression in element content is normalized by normalizing each individual expression in its expression sequence and then constructing a sequence of the normalized values:

[ { Expr₁, ..., Exprn } ]ElementContentUnit

==

[ Expr₁ ]Expr , ..., [ Exprn]Expr

Static Type Analysis

There are no additional static typing rules for direct XML element or attribute constructors.

Dynamic Evaluation

There are no additional dynamic evaluation rules for direct XML element or attribute constructors.

4.7.1.1 Attributes

Like direct element constructors, direct attribute constructors are normalized to computed attribute constructors.

Notation

The auxiliary mapping rules []Attribute, []AttributeContent, and []AttributeContentUnit, are defined in this section and are used for the normalization of direct attribute constructors.

We use the following grammar productions to represent AttributeContentUnits, i.e., the expressions used to compute the content of an attribute.

[87 (Formal)]    | AttributeContentUnits |    ::=    | AttributeContentUnit*
[88 (Formal)]    | AttributeContentUnit |    ::=    | EscapeQuot | QuotAttrValueContent

Normalization

Direct attributes may contain namespace-declaration attributes. The normalization rules in this section ignore namespace-declaration attributes -- they are handled by the normalization rules in [4.7.1.2 Namespace Declaration Attributes].

A DirAttributeList is normalized by the following rule, which maps each of the individual attribute-value expressions in the attribute list and constructs a sequence of the normalized values.

[

QName₁ S? = S? DirAttributeValue 1

...

QNamen S? = S? DirAttributeValue n

]Attribute

==

([QName₁ S? = S? DirAttributeValue 1 ]Attribute

...,

[QNamen S? = S? DirAttributeValue n]Attribute)

Namespace-declaration attributes, i.e., those attributes whose prefix is xmlns are ignored by mapping them to the empty sequence.

[Prefix:LocalPart S? = S? DirAttributeValue ]Attribute

(Prefix = xmlns)

==

()

All attributes that are not namespace-declaration attributes are mapped to computed attribute constructors.

[Prefix:LocalPart S? = S? " AttributeContentUnits "]Attribute

not(Prefix = xmlns)

==

attribute Prefix:LocalPart { [AttributeContentUnits]AttributeContent}

As with literal XML elements, we need to distinguish between direct attribute constructors that contain one attribute-content unit and those that contain multiple attribute-content units, because the rule for converting sequences of atomic values into strings is applied to sequences within distinct enclosed expressions. If the direct attribute constructor contains exactly one attribute-content unit, we simply normalize that unit by applying the normalization rule for attribute content units:

[ AttributeContentUnit₁ ]AttributeContent

==

[AttributeContentUnit₁]AttributeContentUnit

If the direct attribute constructor contains more than one attribute-content unit, we normalize each unit individually and construct a sequence of the normalized results interleaved with empty text nodes. The empty text nodes guarantee that the results of evaluating consecutive attribute-content units can be distinguished. Then we apply the function fs:item-sequence-to-untypedAtomic, which applies the appropriate conversion rules to the normalized attribute content:

[ AttributeContentUnit₁ ... AttributeContentUnitn ]AttributeContent

==

fs:item-sequence-to-untypedAtomic(( [ AttributeContentUnit₁ ]AttributeContentUnit , text { "" }, ..., text {""}, [ AttributeContentUnitn]AttributeContentUnit))

Literal characters, escaped curly braces, character references, and predefined entity references in attribute content are treated as in element content. In addition, the normalization rule for characters in attributes assumes:

that an escaped single or double quote is converted to an individual single or double quote.

The following normalization rules take the longest consecutive sequence of individual characters that include literal characters, escaped curly braces, escaped quotes, character references, predefined entity references, and escaped single and double quotes and normalizes the character sequence as a string.

[( Char | CharRef | EscapeQuot | EscapeApos | PredefinedEntityRef ) +]AttributeContentUnit

==

fn:codepoints-to-string(( Char | CharRef | EscapeQuot | EscapeApos | PredefinedEntityRef )+)

We normalize an enclosed expression by normalizing each individual expression in its expression sequence and then constructing a sequence of the normalized values:

[ { Expr₁, ..., Exprn } ]AttributeContentUnit

==

([ Expr₁ ]Expr , ..., [ Exprn]Expr)

4.7.1.2 Namespace Declaration Attributes

Notation

The auxiliary mapping rules []NamespaceAttr, and []NamespaceAttrs are defined in this section and are used for the normalization of namespace declaration attributes.

Normalization

Some direct attributes may be namespace-declaration attributes. The normalization rules for namespace-declaration attributes ignore all non-namespace attributes -- they are handled by the normalization rules in [4.7.1.1 Attributes].

A DirAttributeList containing namespace-declaration attributes is normalized by the following rule, which maps each of the individual namespace-declaration attributes in the attribute list and constructs a sequence of the normalized namespace attribute values.

[

QName₁ S? = S? DirAttributeValue 1

...

QNamen S? = S? DirAttributeValue n

]NamespaceAttrs

==

([QName₁ S? = S? DirAttributeValue 1]NamespaceAttr

...,

[QNamen S? = S? DirAttributeValue n]NamespaceAttr)

Attributes whose prefix is not xmlns are ignored by mapping them to the empty sequence.

[Prefix:LocalPart S? = S? DirAttributeValue ]NamespaceAttr

not(Prefix = xmlns)

==

()

Namespace-declaration attributes are normalized to local namespace declarations (NamespaceBinding). The content of such attributes must be defined with a URI literal.

[Prefix:LocalPart S? = S? " URILiteral "]NamespaceAttr

(Prefix = xmlns)

==

namespace LocalPart { URILiteral }

4.7.1.3 Content

The rules for normalizing element content are given above in [4.7.1 Direct Element Constructors].

4.7.1.4 Boundary Whitespace

Section 3.7.1.4 Boundary WhitespaceXQ describes how whitespace is processed in element constructors depending on the value of the boundary-space declaration in the query prolog. The Formal Semantics assumes that the rules for handling whitespace are applied by the (informally defined) auxiliary rule []DirCharsUnits.

4.7.2 Other Direct Constructors

Other Constructors

[105 (XQuery)]    | DirPIConstructor XQ |    ::=    | "<?" PITarget (S DirPIContents)? "?>"
[106 (XQuery)]    | DirPIContents XQ |    ::=    | (Char* - (Char* '?>' Char*))
[103 (XQuery)]    | DirCommentConstructor XQ |    ::=    | "<!--" DirCommentContents "-->"
[104 (XQuery)]    | DirCommentContents XQ |    ::=    | ((Char - '-') | ('-' (Char - '-')))*

Notation

The auxiliary mapping rule []Characters is defined in this section and used for the normalization of direct PI and comment constructors.

[Char*]Characters takes the character content of a PI or comment constructor and yields a corresponding StringLiteral.

Normalization

A literal XML processing instruction is normalized into a computed processing-instruction constructor; its character content is converted to a string using the auxiliary mapping rule []Characters.

[<? NCName DirPIContents ?>]Expr

==

[processing-instruction NCName { [DirPIContents]Characters }]Expr

A literal XML comment is normalized into a computed comment constructor; its character content is converted to a string using the auxiliary mapping rule []Characters.

[<!-- DirCommentContents -->]Expr

==

[comment { [DirCommentContents]Characters }]Expr

Static Type Analysis

There are no additional static typing rules for direct processing-instruction or comment constructors.

Dynamic Evaluation

There are no additional dynamic evaluation rules for direct processing-instruction or comment constructors.

4.7.3 Computed Constructors

Computed Constructors

[109 (XQuery)]   
ComputedConstructor XQ
   ::=   
CompDocConstructor
| CompElemConstructor
| CompAttrConstructor
| CompTextConstructor
| CompCommentConstructor
| CompPIConstructor

4.7.3.1 Computed Element Constructors

Introduction

This section describes the semantics of computed element constructors. Remember that direct element constructors are normalized into computed element constructors. This document does not formally specify how namespaces are copied. The semantics of namespaces copying in element constructors can be found in [XQuery 1.0: An XML Query Language].

[111 (XQuery)]    | CompElemConstructor XQ |    ::=    | "element" (QName | ("{" Expr "}")) "{" ContentExpr? "}"
[112 (XQuery)]    | ContentExpr XQ |    ::=    | Expr

Core Grammar

The Core grammar productions for computed element constructors are:

Computed Element Constructors

[67 (Core)]    | CompElemConstructor |    ::=    | "element" (QName | ("{" Expr "}")) "{" ContentExpr "}" "{" NamespaceBinding* "}"
[69 (Core)]    | ContentExpr |    ::=    | Expr
[68 (Core)]    | NamespaceBinding |    ::=    | "namespace" NCName "{" URILiteral "}"

Normalization

If the content expression is missing, the computed element constructor is normalized as if its content expression was the empty sequence.

[element QName { }]Expr

==

[element QName { () }]Expr

Computed element constructors are normalized using the fs:item-sequence-to-node-sequence function over their content expression.

[element QName { Expr }]Expr

==

element QName { fs:item-sequence-to-node-sequence(( [Expr]Expr)) }

When the name of the element is also computed, the normalization rule applies atomization to the name expression.

[element { Expr₁ } { Expr₂ }]Expr

==

element { fn:data(([Expr₁]Expr)) }{ fs:item-sequence-to-node-sequence(( [Expr₂]Expr)) }

Notation

The following auxiliary judgment adds a sequence of namespace bindings to the static context.

add namespace bindings NamespaceBindings to statEnv₁ yields statEnv₂

This judgment is defined as follows.

statEnv  |-  add namespace bindings to statEnv₀ yields statEnv₀

NamespaceBinding 1 = namespace LocalPart₁ { URILiteral₁ }

...

NamespaceBinding n = namespace LocalPartn { URILiteraln }

dynEnvDefault |-  URILiteral₁ has atomic value AnyURI

...

dynEnvDefault |-  URILiteral₁ has atomic value AnyURI

statEnv₁.namespace = statEnv₀ + namespace(LocalPart₁ => (passive, AnyURI₁))

...

statEnvn.namespace = statEnvn-1 + namespace(LocalPartn => (passive, AnyURIn))

statEnv  |-  add namespace bindings NamespaceBinding 1 ... NamespaceBinding n to statEnv₀ yields statEnvn

Static Type Analysis

The normalization rules of direct element and attribute constructors leave us with only the computed forms of constructors. The static semantics for constructors is defined on all the computed forms. The computed element constructor itself has two forms: one in which the element name is a literal QName, and the other in which the element name is a computed expression.

A computed element constructor creates a new element with either the type annotationXQ xs:untyped (in strip construction mode), or with the type annotationXQ xs:anyType (in preserve construction mode). The content expression must return a sequence of nodes with all the attribute nodes before any element, processing-instructions or comment nodes. Note that the type allows text nodes interleaved with attribute nodes in the beginning. Although this results in a looser type checking, this accounts for the possible presence of empty text nodes resulting from normalization of direct element constructors (See [4.7.1 Direct Element Constructors]).

statEnv.constructionMode = preserve

add namespace bindings NamespaceBindings to statEnv₁ yields statEnv₂

statEnv₂ |-  Expr : Type

statEnv₂ |-  Type <: (attribute*, (element | comment | processing-instruction)*) & text*

statEnv₁ |-  element QName { Expr } { NamespaceBindings } : element QName of type xs:anyType

statEnv.constructionMode = strip

add namespace bindings NamespaceBindings to statEnv₁ yields statEnv₂

statEnv₂ |-  Expr : Type

statEnv₂ |-  Type <: (attribute*, (element | comment | processing-instruction)*) & text*

statEnv₁ |-  element QName { Expr } { NamespaceBindings } : element QName of type xs:untyped

In case the element name is computed as well, the name expression must be of type xs:QName, xs:string, or xs:untypedAtomic.

statEnv.constructionMode = preserve

add namespace bindings NamespaceBindings to statEnv₁ yields statEnv₂

statEnv₂ |-  Expr₁ : Type₁

statEnv₂ |-  Type₁ <: (xs:QName | xs:string | xs:untypedAtomic)

statEnv₂ |-  Expr₂ : Type₂

statEnv₂ |-  Type₂ <: (attribute*, (element | comment | processing-instruction)*) & text*

statEnv₁ |-  element { Expr₁ } { Expr₂ } { NamespaceBindings } : element of type xs:anyType

statEnv.constructionMode = strip

add namespace bindings NamespaceBindings to statEnv₁ yields statEnv₂

statEnv₂ |-  Expr₁ : Type₁

statEnv₂ |-  Type₁ <: (xs:QName | xs:string | xs:untypedAtomic)

statEnv₂ |-  Expr₂ : Type₂

statEnv₂ |-  Type₂ <: (attribute*, (element | comment | processing-instruction)*) & text*

statEnv₁ |-  element { Expr₁ } { Expr₂ } { NamespaceBindings } : element of type xs:untyped

Dynamic Evaluation

The following rules take a computed element constructor expression and construct an element node. The dynamic semantics for computed element constructors is the most complex of all expressions in XQuery. Here is how to read the rule below.

First, the element's content expression is partitioned into the local namespace declarations and all other expressions, and the local namespace declarations are evaluated, yielding a sequence of namespace bindings. The static environment is extended to include the new namespace bindings, which are all active. In Section 3.7.1.2 Namespace Declaration AttributesXQ, it is implementation-defined whether undeclaration of namespace prefixes (by setting the namespace prefix to the zero-length string) in an element constructor is supported. In the dynamic semantics below, we assume all local namespace declarations declare a binding of a prefix to a URI.

Second, the expression is evaluated, and the resulting value Value₀ must match zero-or-more attributes followed by zero-or-more element, text, processing-instruction or comment nodes.

Third, the namespace bindings are concatenated with the list of active namespaces in the namespace environment statEnv.namespace and the namespaces corresponding to the element's name and all attributes names. The resulting sequence is the sequence of namespace bindings for the element.

Expr = Expr₀

statEnvn; dynEnv |-  Expr₀ => Value₀

statEnv  |-  Value₀ matches (attribute*, (element | text | processing-instruction | comment)*)

statEnv; dynEnv |-  element QName { Expr } => element QName of type xs:anyType { Value₀ } { }

Expr = NamespaceBinding 1, ..., NamespaceBinding n, Expr₀

NamespaceBinding 1 = namespace NCName₁ { AnyURI₁ }

...

NamespaceBinding n = namespace NCNamen { AnyURIn }

statEnv₁ = statEnv + namespace(NCName₁ => (active, AnyURI₁))

...

statEnvn = statEnvn-1 + namespace(NCNamen => (active, AnyURIn))

statEnvn; dynEnv |-  Expr₀ => Value₀

statEnv  |-  Value₀ matches (attribute*, (element | text | processing-instruction | comment)*)

NamespaceBindings = NamespaceBinding 1, ..., NamespaceBinding n, fs:active_ns(statEnv), fs:get_static_ns_from_items(statEnv, Value₀)

statEnv; dynEnv |-  element QName { Expr } => element QName of type xs:anyType { Value₀ } { NamespaceBindings }

The dynamic evaluation of an element constructor with a computed name is similar. There is one additional rule that checks that the value of the element's name expression matches xs:QName.

dynEnv |- Expr₁ => Value₀

statEnv |-  Value₀ matches xs:QName

QName = fn:prefix-from-QName(Value₀):fn:local-name-from-QName( Value₀)

dynEnv |-  element QName { Expr₂ } => Value

dynEnv |-  element { Expr₁ } { Expr₂ } => Value

4.7.3.2 Computed Attribute Constructors

[113 (XQuery)]   
CompAttrConstructor XQ
   ::=   
"attribute" (QName | ("{" Expr "}")) "{" Expr? "}"

Core Grammar

The Core grammar production for computed attribute constructors is:

Computed Attribute Constructors

[70 (Core)]   
CompAttrConstructor
   ::=   
"attribute" (QName | ("{" Expr "}")) "{" Expr "}"

Normalization

Computed attribute constructors are normalized by mapping their name and content expression in a similar way as computed element constructors. The normalization rule uses the fs:item-sequence-to-untypedAtomic function.

[attribute QName { }]Expr

==

[attribute QName { () }]Expr

[attribute QName { Expr }]Expr

==

attribute QName { fs:item-sequence-to-untypedAtomic(( [Expr]Expr)) }

[attribute { Expr₁ } { Expr₂ }]Expr

==

attribute { fn:data(([Expr₁]Expr)) } { fs:item-sequence-to-untypedAtomic(( [Expr₂]Expr)) }

Static Type Analysis

The normalization rules for direct attribute constructors leave us with only the computed form of the attribute constructors. Like in a computed element constructor, a computed attribute constructor has two forms: one in which the attribute name is a literal QName, and the other in which the attribute name is a computed expression.

In the case of attribute constructors, the type annotationXQ is always xs:untypedAtomic.

statEnv |-  Expr : Type

statEnv  |-  Type <: xs:untypedAtomic

statEnv |-  attribute QName { Expr } : attribute QName of type xs:untypedAtomic

statEnv |-  Expr₁ : Type₁

statEnv |-  Type₁ <: (xs:QName | xs:string | xs:untypedAtomic)

statEnv |-  Expr₂ : Type₂

statEnv |-  Type₂ <: xs:untypedAtomic

statEnv |-  attribute { Expr₁ } { Expr₂ } : attribute of type xs:untypedAtomic

Dynamic Evaluation

The following rules take a computed attribute constructor expression and construct an attribute node. The rules are similar to those rules for element constructors. First, the attribute's name is expanded into a qualified name. Second, the function fs:item-sequence-to-untypedAtomic is applied to the content expression and this function call is evaluated in the dynamic environment. Recall from [4.7.3.2 Computed Attribute Constructors] that during normalization, we do not convert the content of direct attribute constructors that contain one attribute-content unit. This guarantees that useful type information is preserved for static analysis. Since the conversion function fs:item-sequence-to-untypedAtomic was not applied to all attribute constructors during normalization, we have to apply it at evaluation time. (As before, it is possible to elide the application of fs:item-sequence-to-untypedAtomic injected during normalization and the application injected during evaluation.)

dynEnv |-  fs:item-sequence-to-untypedAtomic( Expr) => AtomicValue

dynEnv |-  attribute QName { Expr } => attribute QName of type xs:untypedAtomic { AtomicValue }

dynEnv |-  Expr₁ => Value₁

statEnv |-  Value₁ matches xs:QName

QName₁ = fn:prefix-from-QName(Value₁):fn:local-name-from-QName( Value₁)

dynEnv |-  fs:item-sequence-to-untypedAtomic( Expr₂) => AtomicValue₂

dynEnv |-  attribute { Expr₁ } { Expr₂ } => attribute QName₁ of type xs:untypedAtomic { AtomicValue₂ }

4.7.3.3 Document Node Constructors

[110 (XQuery)]   
CompDocConstructor XQ
   ::=   
"document" "{" Expr "}"

Core Grammar

The Core grammar production for a computed document constructor is:

Core computed document constructor

[66 (Core)]   
CompDocConstructor
   ::=   
"document" "{" Expr "}"

Normalization

A document node constructor contains an expression, which must evaluate to a sequence of element, text, comment, or processing-instruction nodes. Section 3.7.3.3 Document Node ConstructorsXQ specifies the rules for converting a sequence of atomic values and nodes into a sequence of nodes before document construction. The built-in function [7.1.6 The fs:item-sequence-to-node-sequence-doc function] implements this conversion.

[document { Expr }]Expr

==

document { fs:item-sequence-to-node-sequence-doc(( [Expr]Expr)) }

Static Type Analysis

The static typing rule does not need to check that the type of the argument expression is a sequence of element, text, processing-instruction, and comment nodes, as it is already checked by the fs:item-sequence-to-node-sequence-doc introduced during normalization. The type of the entire expression is the most general document type, because the document constructor erases all type annotationXQ on its content nodes.

statEnv |-  Expr : Type

statEnv |-  document { Expr } : document { Type }

Dynamic Evaluation

The dynamic semantics checks that the argument expression evaluates to a value that is a sequence of element, text, processing-instruction, or comment nodes. The entire expression evaluates to a new document node value. If the construction mode is set to strip, the type annotationXQ for all the nodes in content of a document node are erased.

statEnv.constructionMode = preserve

dynEnv |-  Expr => Value

statEnv |-  Value matches (element | text | processing-instruction | comment)*

dynEnv |-  document { Expr } => document { Value }

statEnv.constructionMode = strip

dynEnv |-  Expr => Value₁

Value₁ erases to Value₂

statEnv |-  Value₂ matches (element | text | processing-instruction | comment)*

dynEnv |-  document { Expr } => document { Value₂ }

4.7.3.4 Text Node Constructors

[114 (XQuery)]   
CompTextConstructor XQ
   ::=   
"text" "{" Expr "}"

Core Grammar

The Core grammar production for a computed text constructor is:

[71 (Core)]   
CompTextConstructor
   ::=   
"text" "{" Expr "}"

Normalization

A text node constructor contains an expression, which must evaluate to an xs:string value. Section 3.7.3.4 Text Node ConstructorsXQ specifies the rules for converting a sequence of atomic values into a string prior to construction of a text node. Each node is replaced by its string value. For each adjacent sequence of one or more atomic values returned by an enclosed expression, a untyped atomic value is constructed, containing the canonical lexical representation of all the atomic values, with a single blank character inserted between adjacent values. As formal specification of these conversion rules is not instructive, [7.1.7 The fs:item-sequence-to-untypedAtomic function] implements this conversion.

[text { Expr }]Expr

==

text { (fs:item-sequence-to-untypedAtomic-text( fn:data(([Expr]Expr)))) cast as xs:string? }

Static Type Analysis

The static semantics checks that the argument expression has type xs:string or empty. The type of the entire expression is an optional text node type, as the text node constructor returns the empty sequence if its argument is the empty sequence.

statEnv |-  Expr : xs:string?

statEnv |-  text { Expr } : text?

Dynamic Evaluation

If the argument expression returns the empty sequence, the text node constructor returns the empty sequence.

dynEnv |-  Expr => ()

dynEnv |-  text { Expr } => ()

If the argument expression returns a value of type xs:string, the text node constructor returns a text node with that string as content.

dynEnv |-  Expr => Value      statEnv |-  Value matches xs:string

dynEnv |-  text { Expr } => text { Value }

4.7.3.5 Computed Processing Instruction Constructors

[116 (XQuery)]   
CompPIConstructor XQ
   ::=   
"processing-instruction" (NCName | ("{" Expr "}")) "{" Expr? "}"

Core Grammar

The Core grammar production for computed processing-instruction constructors is:

[73 (Core)]   
CompPIConstructor
   ::=   
"processing-instruction" (NCName | ("{" Expr "}")) "{" Expr? "}"

Normalization

Computed processing-instruction constructors are normalized by mapping their name and content expression in the same way that computed element and attribute constructors are normalized.

[processing-instruction NCName { }]Expr

==

[processing-instruction NCName { () }]Expr

[processing-instruction NCName { Expr }]Expr

==

processing-instruction NCName { fs:item-sequence-to-untypedAtomic-PI(( [Expr]Expr)) }

[processing-instruction { Expr₁ } { Expr₂ }]Expr

==

processing-instruction { fn:data(([Expr₁]Expr)) } { fs:item-sequence-to-untypedAtomic-PI(( [Expr₂]Expr)) }

Static Type Analysis

The static typing rules for processing-instruction constructors are straightforward.

statEnv |-  Expr : xs:untypedAtomic

statEnv |-  processing-instruction NCName { Expr } : processing-instruction

statEnv |-  Expr₁ : (xs:NCName | xs:string | xs:untypedAtomic)      statEnv |-  Expr₂ : xs:untypedAtomic

statEnv |-  processing-instruction { Expr₁ } { Expr₂ } : processing-instruction

Dynamic Evaluation

The dynamic evaluation rules for computed processing-instructions are straightforward.

dynEnv |-  Expr => Value      statEnv |-  Value matches xs:untypedAtomic

dynEnv |-  processing-instruction NCName { Expr } => processing-instruction NCName { Value }

dynEnv |-  Expr₁ => Value₁

statEnv |-  Value₁ matches (xs:NCName | xs:untypedAtomic | xs:string)

xs:NCName(Value₁) = NCName₁

dynEnv |-  Expr₂ => Value₂      statEnv |-  Value₂ matches xs:untypedAtomic

dynEnv |-  processing-instruction { Expr₁ } { Expr₂ } => processing-instruction NCName₁ { Value₂ }

4.7.3.6 Computed Comment Constructors

[115 (XQuery)]   
CompCommentConstructor XQ
   ::=   
"comment" "{" Expr "}"

Core Grammar

The Core grammar production for computed comment constructors is:

[72 (Core)]   
CompCommentConstructor
   ::=   
"comment" "{" Expr "}"

Normalization

Computed comment constructors are normalized by mapping their content expression.

[comment { Expr }]Expr

==

comment { (fs:item-sequence-to-untypedAtomic-comment(( [Expr]Expr))) cast as xs:string }

Static Type Analysis

The static typing rule for computed comment constructors is straightforward.

statEnv |-  Expr : xs:string

statEnv |-  comment { Expr } : comment

Dynamic Evaluation

The dynamic evaluation rule for computed comment constructors is straightforward.

dynEnv |-  Expr => Value      statEnv |-  Value matches xs:string

dynEnv |-  comment { Expr } => comment { Value }

4.7.4 In-scope Namespaces of a Constructed Element

The effect of in-scope namespaces on constructed elements is specified in [4.7.1 Direct Element Constructors] and [4.7.3.1 Computed Element Constructors].

4.8 [For/FLWOR] Expressions

Introduction

[XPath/XQuery] provides [For/FLWOR] expressions for iteration, for binding variables to intermediate results, and filtering bound variables according to a predicate.

A FLWORExpr in XQuery 1.0 consists of a sequence of ForClauses and LetClauses, followed by an optional WhereClause, followed by an optional OrderByClause, as described by the following grammar productions. Each variable binding is preceded by an optional type declaration which specify the type expected for the variable.

The dynamic semantics of the ordering mode in FLWOR expressions is not specified formally, as it would require the introduction of tuples, which are not supported in the [XPath/XQuery] data model.

[For/FLWOR] Expressions

[33 (XQuery)]    | FLWORExpr XQ |    ::=    | (ForClause | LetClause)+ WhereClause? OrderByClause? "return" ExprSingle
[34 (XQuery)]    | ForClause XQ |    ::=    | "for" "$" VarName TypeDeclaration? PositionalVar? "in" ExprSingle ("," "$" VarName TypeDeclaration? PositionalVar? "in" ExprSingle)*
[36 (XQuery)]    | LetClause XQ |    ::=    | "let" "$" VarName TypeDeclaration? ":=" ExprSingle ("," "$" VarName TypeDeclaration? ":=" ExprSingle)*
[118 (XQuery)]    | TypeDeclaration XQ |    ::=    | "as" SequenceType
[35 (XQuery)]    | PositionalVar XQ |    ::=    | "at" "$" VarName
[37 (XQuery)]    | WhereClause XQ |    ::=    | "where" ExprSingle
[38 (XQuery)]    | OrderByClause XQ |    ::=    | (("order" "by") | ("stable" "order" "by")) OrderSpecList
[39 (XQuery)]    | OrderSpecList XQ |    ::=    | OrderSpec ("," OrderSpec)*
[40 (XQuery)]    | OrderSpec XQ |    ::=    | ExprSingle OrderModifier
[41 (XQuery)]    | OrderModifier XQ |    ::=    | ("ascending" | "descending")? ("empty" ("greatest" | "least"))? ("collation" URILiteral)?
[4 (XPath)]    | ForExpr XP |    ::=    | SimpleForClause "return" ExprSingle
[5 (XPath)]    | SimpleForClause XP |    ::=    | "for" "$" VarName "in" ExprSingle ("," "$" VarName "in" ExprSingle)*

Core Grammar

The Core grammar productions for FLWOR expressions are:

For Expressions

[24 (Core)]    | FLWORExpr |    ::=    | (ForClause | LetClause) "return" ExprSingle
[25 (Core)]    | ForClause |    ::=    | "for" "$" VarName TypeDeclaration? PositionalVar? "in" ExprSingle
[27 (Core)]    | LetClause |    ::=    | "let" "$" VarName TypeDeclaration? ":=" ExprSingle
[26 (Core)]    | PositionalVar |    ::=    | "at" "$" VarName
[75 (Core)]    | TypeDeclaration |    ::=    | "as" SequenceType
[28 (Core)]    | OrderByClause |    ::=    | (("order" "by") | ("stable" "order" "by")) OrderSpecList
[29 (Core)]    | OrderSpecList |    ::=    | OrderSpec ("," OrderSpec)*
[30 (Core)]    | OrderSpec |    ::=    | ExprSingle OrderModifier
[31 (Core)]    | OrderModifier |    ::=    | ("ascending" | "descending")? ("empty" ("greatest" | "least"))? ("collation" URILiteral)?

4.8.1 FLWOR expressions

Notation

For convenience, we introduce the following auxiliary grammar productions to represent optional type declarations and positional variables in For and Let clauses.

[79 (Formal)]    | OptTypeDeclaration |    ::=    | TypeDeclaration?
[80 (Formal)]    | OptPositionalVar |    ::=    | PositionalVar?

Notation

To facilitate the specification of normalization, we also introduce the following auxiliary grammar productions as an alternative grammar for FLWOR expressions.

[65 (Formal)]    | FormalFLWORClause |    ::=    | ForClause | LetClause | WhereClause | OrderByClause
[66 (Formal)]    | FormalReturnClause |    ::=    | FormalFLWORExpr | ("return" Expr)
[67 (Formal)]    | FormalFLWORExpr |    ::=    | FormalFLWORClause FormalReturnClause

Normalization

Full FLWOR expressions are normalized to nested Core FLWOR expressions with a single for or let clause. Note that some of the normalization rules below accept ungrammatical FLWOR expressions such as "where Expr₁ return Expr₂". This does not matter, as normalization is always applied on parsed [XPath/XQuery] expressions, and such ungrammatical FLWOR expressions would be rejected by the parser beforehand.

Normalized FLWOR expressions restrict a For and Let clause to bind only one variable. Otherwise, the Core FLWOR expression is the same as the XQuery FLWOR expression. The first normalization rule is applied on a full [For/FLWOR] expression, splitting it at the clause level, then applying further normalization on each separate clause.

[

for $VarName₁ OptTypeDeclaration₁ OptPositionalVar₁ in Expr₁,

···,

$VarNamen OptTypeDeclarationn OptPositionalVarn in Exprn

FormalReturnClause

] Expr

==

for $VarName₁ OptTypeDeclaration₁ OptPositionalVar₁ in [Expr₁]Expr return

  ···

     for $VarNamen OptTypeDeclarationn OptPositionalVarn in [ Exprn ]Expr return

[FormalReturnClause]Expr

Likewise, a LetClause clause is normalized to nested let expressions, each of which binds one variable:

[

let $VarName₁ OptTypeDeclaration₁ := Expr₁,

···,

$VarNamen OptTypeDeclarationn := Exprn

FormalReturnClause

]Expr

==

let $VarName₁ OptTypeDeclaration₁ := [Expr₁ ]Expr return

  ···

    let $VarNamen OptTypeDeclarationn := [Exprn]Expr return

[FormalReturnClause]Expr

A WhereClause is normalized to an IfExpr, with the else-branch returning the empty sequence:

[ where Expr₁ FormalReturnClause]Expr

==

if ( [Expr₁]Expr ) then [FormalReturnClause]Expr else ()

The order by clause is normalized using the auxiliary mapping rule []OrderSpecList which is defined in [4.8.4 Order By and Return Clauses].

[ stable? order by OrderSpecList FormalReturnClause]Expr

==

[OrderSpecList]OrderSpecList return [FormalReturnClause]Expr

Finally, a stand-alone return clause is normalized into the corresponding expression. Recall that return keywords are introduced in the previous rule after the normalization of each clause.

[ return Expr ]Expr

==

[ Expr ]Expr

Example

The following simple example illustrates how a FLWORExpr is normalized. The for expression in the example below is used to iterate over two collections, binding variables $i and $j to items in these collections. It uses a let clause to bind the local variable $k to the sum of both numbers, and a where clause to select only those numbers that have a sum equal to or greater than the integer 5.

  for $i as xs:integer in (1, 2),
      $j in (3, 4)
  let $k := $i + $j
  where $k >= 5
  return
    <tuple>
       <i> { $i } </i>
       <j> { $j } </j>
    </tuple>

By the first set of rules, this is normalized to (except for the operators and element constructor which are not treated here):

  for $i as xs:integer in (1, 2) return
    for $j in (3, 4) return
      let $k := $i + $j return
        if ($k >= 5) then
          <tuple>
            <i> { $i } </i>
            <j> { $j } </j>
          </tuple>
        else
          ()

For each binding of $i to an item in the sequence (1 , 2) the inner for expression iterates over the sequence (3 , 4) to produce tuples ordered by the ordering of the outer sequence and then by the ordering of the inner sequence. This Core expression eventually results in the following document fragment:

  (<tuple>
      <i>1</i>
      <j>4</j>
   </tuple>,
   <tuple>
      <i>2</i>
      <j>3</j>
   </tuple>,
   <tuple>
      <i>2</i>
      <j>4</j>
   </tuple>)

4.8.2 For expression

Static Type Analysis

A single for expression is typed as follows: First Type₁ of the iteration expression Expr₁ is inferred. Then the prime type of Type₁, prime(Type₁), is computed. This is a union over all item types in Type₁ (See [8.4 Judgments for FLWOR and other expressions on sequences]). With the variable component of the static environment statEnv extended with $VarName₁ as type prime(Type₁), the type Type₂ of Expr₂ is inferred. Because the for expression iterates over the result of Expr₁, the final type of the iteration is Type₂ multiplied with the possible number of items in Type₁ (one, ?, *, or +). This number is determined by the auxiliary type-function quantifier(Type₁). Operations between quantifiers and types, such as Type₂ · quantifier(Type₁), used in the following rule, are defined in [8.4 Judgments for FLWOR and other expressions on sequences].

statEnv |-  Expr₁ : Type₁

statEnv |-  VarName₁ of var expands to Variable₁

statEnv + varType(Variable₁ => prime(Type₁))  |-  Expr₂ : Type₂

statEnv |-  for $VarName₁ in Expr₁ return Expr₂ : Type₂ · quantifier(Type₁)

When a positional variable Variablepos is present, the static environment is also extended with the positional variable typed as an xs:integer.

statEnv |-  Expr₁ : Type₁

statEnv |-  VarName₁ of var expands to Variable₁

statEnv |-  VarNamepos of var expands to Variablepos

statEnv + varType(Variable₁ => prime(Type₁);Variablepos => xs:integer)  |-  Expr₂ : Type₂

statEnv |-  for $VarName₁ at $VarNamepos in Expr₁ return Expr₂ : Type₂ · quantifier(Type₁)

When a type declaration is present, the static semantics also checks that the type of the input expression is a subtype of the declared type and extends the static environment by typing $VarName₁ with type Type₀. This semantics is specified by the following static typing rule.

statEnv |-  Expr₁ : Type₁

Type₀ = [ SequenceType ]sequencetype

statEnv  |-  prime(Type₁) <: Type₀

statEnv |-  VarName₁ of var expands to Variable₁

statEnv + varType(Variable₁ => Type₀)  |-  Expr₂ : Type₂

statEnv |-  for $VarName₁ as SequenceType in Expr₁ return Expr₂ : Type₂ · quantifier(Type₁)

The last rule handles For expressions that contain a type declaration and a positional variable. When the positional variable is present, the static environment is also extended with the positional variable typed as an integer.

statEnv |-  Expr₁ : Type₁

Type₀ = [ SequenceType ]sequencetype

statEnv  |-  prime(Type₁) <: Type₀

statEnv |-  VarName₁ of var expands to Variable₁

statEnv |-  VarNamepos of var expands to Variablepos

statEnv + varType(Variable₁ => Type₀; Variablepos => xs:integer)  |-  Expr₂ : Type₂

statEnv |-  for $VarName₁ as SequenceType at $VarNamepos in Expr₁ return Expr₂ : Type₂ · quantifier(Type₁)

Example

For example, if $example is bound to the sequence 10.0, 1.0E1, 10 of type xs:decimal, xs:float, xs:integer, then the query

  for $s in $example
  return $s * 2

is typed as follows:

  (1) prime(xs:decimal, xs:float, xs:integer) =
      xs:decimal | xs:float | xs:integer
  (2) quantifier(xs:decimal, xs:float, xs:integer) = +
  (3) $s : xs:decimal | xs:float | xs:integer
  (4) $s * 2 :
      xs:decimal | xs:float | xs:integer
  (5) result-type :
      ( xs:decimal | xs:float | xs:integer ) +

This result-type is not the most specific type possible. It does not take into account the order of elements in the input type, and it ignores the individual and overall number of elements in the input type. The most specific type possible is: xs:decimal, xs:float, xs:integer. However, inferring such a specific type for arbitrary input types and arbitrary return clauses requires significantly more complex static typing rules. In addition, if put into the context of an element, the specific type violates the "unique particle attribution" restriction of XML schema, which requires that an element must have a unique content model within a particular context.

Dynamic Evaluation

The evaluation of a for expression distinguishes two cases: If the iteration expression Expr₁ evaluates to the empty sequence, then the entire expression evaluates to the empty sequence:

dynEnv |-  Expr₁ => ()

dynEnv |-  for $VarName₁ OptTypeDeclaration OptPositionalVar in Expr₁ return Expr₂ => ()

Otherwise, the iteration expression Expr₁ is evaluated to produce the sequence Item₁, ..., Itemn. For each item Itemi in this sequence, the body of the for expression Expr₂ is evaluated in the dynamic environment dynEnv extended with $VarName₁ bound to Itemi. This produces values Valuei, ..., Valuen which are concatenated to produce the result sequence.

dynEnv |-  Expr₁ => Item₁ ,..., Itemn

statEnv  |-  VarName of var expands to Variable

dynEnv + varValue(Variable => Item₁)  |-  Expr₂ => Value₁

···

dynEnv + varValue(Variable => Itemn)  |-  Expr₂ => Valuen

dynEnv |-  for $VarName in Expr₁ return Expr₂ => Value₁ ,..., Valuen

The following rule is the same as the rule above, but includes the optional positional variable $VarNamepos. If present, $VarNamepos is bound to the position of the item in the input sequence, i.e., the value i.

dynEnv |-  Expr₁ => Item₁ ,..., Itemn

statEnv  |-  VarName of var expands to Variable      statEnv  |-  VarNamepos of var expands to Variablepos

dynEnv + varValue(Variable => Item₁; Variablepos => 1)  |-  Expr₂ => Value₁

···

dynEnv + varValue(Variable => Itemn; Variablepos => n)  |-  Expr₂ => Valuen

dynEnv |-  for $VarName at $VarNamepos in Expr₁ return Expr₂ => Value₁ ,..., Valuen

When a type declaration is present, the dynamic semantics also checks that each item in the result of evaluating Expr₁ matches the declared type. This semantics is specified by the following dynamic evaluation rule.

dynEnv |-  Expr₁ => Item₁ ,..., Itemn

Type₀ = [ SequenceType ]sequencetype

statEnv  |-  Item₁ matches Type₀

···

statEnv  |-  Itemn matches Type₀

statEnv  |-  VarName of var expands to Variable

dynEnv + varValue(Variable => Item₁)  |-  Expr₂ => Value₁

···

dynEnv + varValue(Variable => Itemn)  |-  Expr₂ => Valuen

dynEnv |-  for $VarName as SequenceType in Expr₁ return Expr₂ => Value₁ ,..., Valuen

The last rule covers a for expression that contains a type declaration and a positional variable.

dynEnv |-  Expr₁ => Item₁ ,..., Itemn

Type₀ = [ SequenceType ]sequencetype

statEnv  |-  Item₁ matches Type₀

···

statEnv  |-  Itemn matches Type₀

statEnv  |-  VarName of var expands to Variable

statEnv  |-  VarNamepos of var expands to Variablepos

dynEnv + varValue(Variable => Item₁; Variablepos => 1)  |-  Expr₂ => Value₁

···

dynEnv + varValue(Variable => Itemn; Variablepos => n)  |-  Expr₂ => Valuen

dynEnv |-  for $VarName as SequenceType at $VarNamepos in Expr₁ return Expr₂ => Value₁ ,..., Valuen

Note that this definition allows non-deterministic evaluation of the resulting sequence, since the preconditions in the above rule can be evaluated in any order.

Example

Note that if the expression in the return clause results in a sequence, sequences are never nested in the [XPath/XQuery] data model. For instance, in the following for expression:

  for $i in (1,2)
    return (<i> {$i} </i>, <negi> {-$i} </negi>)

each iteration in the for results in a sequence of two elements, which are then concatenated and flattened in the resulting sequence:

  (<i>1</i>,
   <negi>-1</negi>,
   <i>2</i>,
   <negi>-2</negi>)

4.8.3 Let Expression

Static Type Analysis

A let expression extends the static environment statEnv with Variable₁ of type Type₁ inferred from Expr₁, and infers the type of Expr₂ in the extended environment to produce the result type Type₂.

statEnv |-  Expr₁ : Type₁      statEnv  |-  VarName of var expands to Variable      statEnv + varType(Variable => Type₁)  |-  Expr₂ : Type₂

statEnv |-  let $VarName := Expr₁ return Expr₂ : Type₂

When a type declaration is present, the static semantics also checks that the type of the input expression is a subtype of the declared type and extends the static environment by typing Variable₁ with type Type₀. This semantics is specified by the following static typing rule.

statEnv |-  Expr₁ : Type₁

Type₀ = [ SequenceType ]sequencetype

statEnv  |-  Type₁ <: Type₀

statEnv  |-  VarName of var expands to Variable      statEnv + varType(Variable₁ => Type₀ )  |-  Expr₂ : Type₂

statEnv |-  let $VarName₁ as SequenceType := Expr₁ return Expr₂ : Type₂

Dynamic Evaluation

A let expression extends the dynamic environment dynEnv with Variable bound to Value₁ returned by Expr₁, and evaluates Expr₂ in the extended environment to produce Value₂.

dynEnv |-  Expr₁ => Value₁

statEnv  |-  VarName of var expands to Variable      dynEnv + varValue(Variable₁ => Value₁)  |-  Expr₂ => Value₂

dynEnv |-  let $VarName₁ := Expr₁ return Expr₂ => Value₂

When a type declaration is present, the dynamic semantics also checks that the result of evaluating Expr₁ matches the declared type. This semantics is specified as the following dynamic evaluation rule.

dynEnv |-  Expr₁ => Value₁

Type₀ = [ SequenceType ]sequencetype

statEnv  |-  Value₁ matches Type₀

statEnv  |-  VarName of var expands to Variable      dynEnv + varValue(Variable₁ => Value₁)  |-  Expr₂ => Value₂

dynEnv |-  let $VarName₁ as SequenceType := Expr₁ return Expr₂ => Value₂

Example

Note the use of the environments to define the scope of each variable. For instance, in the following nested let expression:

  let $k := 5 return
    let $k := $k + 1 return
      $k+1

the outermost let expression binds variable $k to the integer 5 in the environment, then the expression $k+1 is computed, yielding value 6, to which the second variable $k is bound. The expression then results in the final integer 7.

4.8.4 Order By and Return Clauses

Introduction

The dynamic semantics of the OrderByClause is not specified formally, as doing so would require the introduction of tuples, which are not supported in the [XPath/XQuery] data model. The dynamic semantics of the order-by clause can be found in Section 3.8.3 Order By and Return ClausesXQ.

Although an OrderByClause does not affect the type of a FLWORExpr expression, it must still undergo static analysis, in case this raises a static error. The static semantics of a FLWORExpr expression with an OrderByClause is equivalent to the static semantics of an equivalent FLWORExpr in which the OrderByClause is replaced by a call to the gt comparison over the corresponding OrderSpec expression(s).

Notation

To define normalization of OrderBy, the following auxiliary mapping rule is used.

[OrderSpecList]OrderSpecList

==

LetClause ... LetClause

This rules specifies that OrderSpecList is mapped to a sequence of LetClauses.

Normalization

Proper static typing for FLWOR expressions with an OrderByClause is obtained by normalizing the OrderByClause to a Let clause, nested For expressions, and atomization, then by applying the standard static typing rules for those expressions. Note that if evaluated dynamically, the normalization of OrderByClause given here does not express the required sorting semantics. Notably, the normalization rule introduces the gt operation which is used implicitely in the semantics of order by.

Each OrderSpec is normalized by the following rules.

[OrderSpec₁ ... OrderSpecn]OrderSpecList

==

[OrderSpec₁]OrderSpecList, ... [OrderSpecn]OrderSpecList

[Expr OrderModifier]OrderSpecList

==

let $fs:new₀ :=

   let $fs:new₁ := [Expr]Expr return

   for $fs:new₂ in $fs:new₁ return

   for $fs:new₃ in $fs:new₁ return

     [$fs:new₂ gt $fs:new₃]Expr

[OrderSpecList]OrderSpecList

4.9 Ordered and Unordered Expressions

Introduction

The purpose of ordered and unordered expressions is to set the ordering mode in the static context to ordered or unordered for a certain region in a query. The specified ordering mode applies to the expression nested inside the curly braces.

[91 (XQuery)]    | OrderedExpr XQ |    ::=    | "ordered" "{" Expr "}"
[92 (XQuery)]    | UnorderedExpr XQ |    ::=    | "unordered" "{" Expr "}"

Core Grammar

The Core grammar productions for ordered/unordered expressions are:

[61 (Core)]    | OrderedExpr |    ::=    | "ordered" "{" Expr "}"
[62 (Core)]    | UnorderedExpr |    ::=    | "unordered" "{" Expr "}"

Normalization

OrderedExpr (resp. UnorderedExpr) expressions are normalized to OrderedExpr (resp. UnorderedExpr) expressions in the [XPath/XQuery] Core.

[ordered { Expr }]Expr

==

ordered { [Expr]Expr }

[unordered { Expr }]Expr

==

unordered { [Expr]Expr }

Static Type Analysis

OrderedExpr and UnorderedExpr expressions set the ordering mode in the static context to ordered or unordered.

statEnv₁ = statEnv + orderingMode(ordered)

statEnv₁ |-  Expr : Type

statEnv |-  ordered { Expr } : Type

statEnv₁ = statEnv + orderingMode(unordered)

statEnv₁ |-  Expr : Type

statEnv |-  unordered { Expr } : Type

Dynamic Evaluation

OrderedExpr and UnorderedExpr expressions only have an effect on the static context. The effect on the evaluation of its subexpression(s) is captured using the fs:apply-ordering-mode function, which introduced during normalization of axis steps, union, intersect, and except expressions, and FLWOR expressions that have no order by clause.

dynEnv |-  Expr => Value

dynEnv |-  ordered { Expr } => Value

dynEnv |-  Expr => Value

dynEnv |-  unordered { Expr } => Value

4.10 Conditional Expressions

Introduction

A conditional expression supports conditional evaluation of one of two expressions.

Conditional Expression

[45 (XQuery)]   
IfExpr XQ
   ::=   
"if" "(" Expr ")" "then" ExprSingle "else" ExprSingle

Core Grammar

The Core grammar production for the conditional expression is:

Core Conditional Expression

[35 (Core)]   
IfExpr
   ::=   
"if" "(" Expr ")" "then" ExprSingle "else" ExprSingle

Normalization

Conditional expressions are normalized as follows.

[if (Expr₁) then Expr₂ else Expr₃]Expr

==

  if (fn:boolean(([ Expr₁ ]Expr))) then [Expr₂]Expr else [Expr₃]Expr

Static Type Analysis

statEnv |-  Expr₁ : xs:boolean      statEnv |-  Expr₂ : Type₂      statEnv |-  Expr₃ : Type₃

statEnv |-  if (Expr₁) then Expr₂ else Expr₃ : (Type₂ | Type₃)

Dynamic Evaluation

If the conditional's boolean expression Expr₁ evaluates to true, Expr₂ is evaluated and its value is produced. If the conditional's boolean expression evaluates to false, Expr₃ is evaluated and its value is produced. Note that the existence of two separate dynamic evaluation rules ensures that only one branch of the conditional is evaluated.

dynEnv |-  Expr₁ => true      dynEnv |-  Expr₂ => Value₂

dynEnv |-  if (Expr₁) then Expr₂ else Expr₃ => Value₂

dynEnv |-  Expr₁ => false      dynEnv |-  Expr₃ => Value₃

dynEnv |-  if (Expr₁) then Expr₂ else Expr₃ => Value₃

4.11 Quantified Expressions

Introduction

[XPath/XQuery] defines two quantification expressions:

Quantified Expression

[42 (XQuery)]    | QuantifiedExpr XQ |    ::=    | ("some" | "every") "$" VarName TypeDeclaration? "in" ExprSingle ("," "$" VarName TypeDeclaration? "in" ExprSingle)* "satisfies" ExprSingle
[6 (XPath)]    | QuantifiedExpr XP |    ::=    | ("some" | "every") "$" VarName "in" ExprSingle ("," "$" VarName "in" ExprSingle)* "satisfies" ExprSingle

Core Grammar

The Core grammar production for quantified expressions is:

[32 (Core)]   
QuantifiedExpr
   ::=   
("some" | "every") "$" VarName TypeDeclaration? "in" ExprSingle ("," "$" VarName TypeDeclaration? "in" ExprSingle)* "satisfies" ExprSingle

Normalization

The quantified expressions are normalized into nested Core quantified expressions, each of which binds one variable.

[some $VarName₁ in Expr₁, ..., $VarNamen in Exprn satisfies Expr]Expr

==

some $VarName₁ in [Expr₁]Expr satisfies

   some $VarName₂ in [Expr₂]Expr satisfies

         ...

     some $VarNamen in [Exprn]Expr satisfies

     fn:boolean(([Expr]Expr))

[every $VarName₁ in Expr₁, ..., $VarNamen in Exprn satisfies Expr]Expr

==

every $VarName₁ in [Expr₁]Expr satisfies

   every $VarName₂ in [Expr₂]Expr satisfies

         ...

     every $VarNamen in [Exprn]Expr satisfies

     fn:boolean(([Expr]Expr))

Static Type Analysis

The static semantics of the quantified expressions uses the notion of prime type. These rules are similar to those for for expressions in [4.8.2 For expression].

statEnv |-  Expr₁ : Type₁

statEnv  |-  VarName₁ of var expands to Variable₁

statEnv + varType(Variable₁ => prime(Type₁))  |-  Expr₂ : xs:boolean

statEnv |-  some $VarName₁ in Expr₁ satisfies Expr₂ : xs:boolean

The next rule is for SomeExpr with the optional type declaration.

statEnv |-  Expr₁ : Type₁

Type₀ = [ SequenceType ]sequencetype

statEnv  |-  prime(Type₁) <: Type₀

statEnv  |-  VarName₁ of var expands to Variable₁

statEnv + varType(Variable₁ => Type₀)  |-  Expr₂ : xs:boolean

statEnv |-  some $VarName₁ as SequenceType in Expr₁ satisfies Expr₂ : xs:boolean

The next rule is for EveryExpr without the optional type declaration.

statEnv |-  Expr₁ : Type₁

statEnv  |-  VarName₁ of var expands to Variable₁

statEnv + varType(Variable₁ => prime(Type₁))  |-  Expr₂ : xs:boolean

statEnv |-  every $VarName₁ in Expr₁ satisfies Expr₂ : xs:boolean

The next rule is for EveryExpr with the optional type declaration.

statEnv |-  Expr₁ : Type₁

Type₀ = [ SequenceType ]sequencetype

statEnv  |-  prime(Type₁) <: Type₀

statEnv  |-  VarName₁ of var expands to Variable₁

statEnv + varType(Variable₁ => Type₀)  |-  Expr₂ : xs:boolean

statEnv |-  every $VarName₁ as SequenceType in Expr₁ satisfies Expr₂ : xs:boolean

Dynamic Evaluation

If its input expression returns the empty sequence, the SomeExpr expression returns false.

dynEnv |-  Expr₁ => ()

dynEnv |-  some $VarName₁ OptTypeDeclaration in Expr₁ satisfies Expr₂ => false

The SomeExpr expression yields true if any evaluation of the satisfies expression yields true. The SomeExpr expression yields false if every evaluation of the satisfies expression is false. A quantified expression may raise an error if any evaluation of the satisfies expression raises an error. The dynamic semantics of quantified expressions is non-deterministic. This non-determinism permits implementations to use short-circuit evaluation strategies when evaluating quantified expressions.

dynEnv |-  Expr₁ => Item₁, ..., Itemn

statEnv  |-  VarName₁ of var expands to Variable₁

dynEnv + varValue(Variable₁ => Itemi)  |-  Expr₂ => true

i in { 1,...,n }

dynEnv |-  some $VarName₁ in Expr₁ satisfies Expr₂ => true

The next rule is for SomeExpr with the optional type declaration, in which some evaluation of the satisfies expression yields true.

dynEnv |-  Expr₁ => Item₁, ..., Itemn

Type₀ = [ SequenceType ]sequencetype

statEnv  |-  Itemi matches Type₀

i in { 1,...,n }

statEnv  |-  VarName₁ of var expands to Variable₁

dynEnv + varValue(Variable₁ => Itemi)  |-  Expr₂ => true

dynEnv |-  some $VarName₁ as SequenceType in Expr₁ satisfies Expr₂ => true

The next rule is for SomeExpr without the optional type declaration, in which all evaluations of the satisfies expression yield false.

dynEnv |-  Expr₁ => Item₁, ..., Itemn

statEnv  |-  VarName₁ of var expands to Variable₁

dynEnv + varValue(Variable₁ => Item₁)  |-  Expr₂ => false

...

dynEnv + varValue(Variable₁ => Itemn)  |-  Expr₂ => false

dynEnv |-  some $VarName₁ in Expr₁ satisfies Expr₂ => false

The next rule is for SomeExpr with the optional type declaration, in which all evaluations of the satisfies expression yield false.

dynEnv |-  Expr₁ => Item₁, ..., Itemn

Type₀ = [ SequenceType ]sequencetype

statEnv  |-  VarName₁ of var expands to Variable₁

dynEnv + varValue(Variable₁ => Item₁)  |-  Expr₂ => false

statEnv  |-  Item₁ matches Type₀

...

dynEnv + varValue(Variable₁ => Itemn)  |-  Expr₂ => false

statEnv  |-  Itemn matches Type₀

dynEnv |-  some $VarName₁ as SequenceType in Expr₁ satisfies Expr₂ => false

If its input expression returns the empty sequence, the EveryExpr expression returns true.

dynEnv |-  Expr₁ => ()

dynEnv |-  every $VarName₁ OptTypeDeclaration in Expr₁ satisfies Expr₂ => true

The EveryExpr expression yields false if any evaluation of the satisfies expression yields false. The EveryExpr expression yields true if every evaluation of the satisfies expression is true.

dynEnv |-  Expr₁ => Item₁, ..., Itemn

statEnv  |-  VarName₁ of var expands to Variable₁

dynEnv + varValue(Variable₁ => Itemi)  |-  Expr₂ => false

i in { 1,...,n }

dynEnv |-  every $VarName₁ in Expr₁ satisfies Expr₂ => false

The next rule is for EveryExpr with the optional type declaration, in which some evaluation of the satisfies expression yields false.

dynEnv |-  Expr₁ => Item₁, ..., Itemn

Type₀ = [ SequenceType ]sequencetype

statEnv  |-  Itemi matches Type₀

statEnv  |-  VarName₁ of var expands to Variable₁

dynEnv + varValue(Variable₁ => Itemi)  |-  Expr₂ => false

i in { 1,...,n }

dynEnv |-  every $VarName₁ as SequenceType in Expr₁ satisfies Expr₂ => false

The next rule is for EveryExpr in which all evaluations of the satisfies expression yield true.

dynEnv |-  Expr₁ => Item₁, ..., Itemn

statEnv  |-  VarName₁ of var expands to Variable₁

dynEnv + varValue(Variable₁ => Item₁)  |-  Expr₂ => true

...

dynEnv + varValue(Variable₁ => Itemn)  |-  Expr₂ => true

dynEnv |-  every $VarName₁ in Expr₁ satisfies Expr₂ => true

The next rule is for EveryExpr with the optional type declaration in which all evaluations of the satisfies expression yield true.

dynEnv |-  Expr₁ => Item₁, ..., Itemn

Type₀ = [ SequenceType ]sequencetype

statEnv  |-  VarName₁ of var expands to Variable₁

dynEnv + varValue(Variable₁ => Item₁)  |-  Expr₂ => true

statEnv  |-  Item₁ matches Type₀

...

dynEnv + varValue(Variable₁ => Itemn)  |-  Expr₂ => true

statEnv  |-  Itemn matches Type₀

dynEnv |-  every $VarName₁ as SequenceType in Expr₁ satisfies Expr₂ => true

4.12 Expressions on SequenceTypes

Introduction

Some of the expressions relying on the SequenceTypes syntax are called expressions on SequenceTypes. The syntax of SequenceTypes is described in [3.5.3 SequenceType Syntax].

4.12.1 Instance Of

SequenceType expressions

[54 (XQuery)]   
InstanceofExpr XQ
   ::=   
TreatExpr ( "instance" "of" SequenceType )?

Introduction

The SequenceType expression "Expr instance of SequenceType" is true if and only if the result of evaluating expression Expr is an instance of the type referred to by SequenceType.

Normalization

An InstanceofExpr expression is normalized into a TypeswitchExpr expression. Note that the following normalization rule uses a variable $fs:new, which is a newly created variable which must not conflict with any variables already in scope. This variable is necessary to comply with the syntax of typeswitch expressions in the Core [XPath/XQuery], but is never used.

[Expr instance of SequenceType]Expr

==

typeswitch ([ Expr ]Expr)

  case $fs:new as SequenceType return fn:true()

  default $fs:new return fn:false()

4.12.2 Typeswitch

SequenceType expressions

[43 (XQuery)]    | TypeswitchExpr XQ |    ::=    | "typeswitch" "(" Expr ")" CaseClause+ "default" ("$" VarName)? "return" ExprSingle
[44 (XQuery)]    | CaseClause XQ |    ::=    | "case" ("$" VarName "as")? SequenceType "return" ExprSingle

Introduction

The typeswitch expression chooses one of several expressions to evaluate based on the dynamic type of an input value.

Each branch of a typeswitch expression may have an optional $VarName, which is bound to the value of the input expression. One reason for using a variable on one of the branches is that it is assigned a type specific for that branch. This variable is optional in [XPath/XQuery] but made mandatory in the [XPath/XQuery] Core.

Core Grammar

The Core grammar productions for typeswitch are:

[33 (Core)]    | TypeswitchExpr |    ::=    | "typeswitch" "(" Expr ")" CaseClause+ "default" "$" VarName "return" ExprSingle
[34 (Core)]    | CaseClause |    ::=    | "case" "$" VarName "as" SequenceType "return" ExprSingle

Notation

For convenience, we introduce the following auxiliary grammar production.

[81 (Formal)]   
OptVarName
   ::=   
("$" VarName)?

Notation

To define normalization of case clauses to the [XPath/XQuery] Core, the following auxiliary mapping rules are used.

[CaseClause]Case

==

CaseClause

specifies that CaseClause is mapped to CaseClause, in the [XPath/XQuery] Core.

Normalization

Normalization of a typeswitch expression guarantees that every branch has an associated $VarName. The following normalization rules add newly created variables that must not conflict with any variables already in scope.

[   case SequenceType return Expr ]Case

==

  case $fs:new₁ as SequenceType return [ Expr ]Expr

[   case $VarName as SequenceType return Expr ]Case

==

  case $VarName as SequenceType return [ Expr ]Expr

[ default return Expr ]Case

==

default $fs:new₁ return [ Expr ]Expr

[ default $VarName return Expr ]Case

==

default $VarName return [ Expr ]Expr

[

typeswitch ( Expr₀ )

  CaseClause₁

    ···

  CaseClausen

  default OptVarName return Exprn+1

]Expr

==

typeswitch ( [ Expr₀ ]Expr )

[CaseClause₁]Case

    ···

[CaseClausen]Case

[  default OptVarName return Exprn+1 ]Case

Notation

For convenience, we use the following auxiliary grammar productions to denote case clauses in a typeswitch.

FormalCaseClauses

[68 (Formal)]    | FormalCaseClauses |    ::=    | (FormalCaseClause FormalCaseClauses) | FormalDefaultCaseClause
[69 (Formal)]    | FormalCaseClause |    ::=    | "case" "$" VarName "as" SequenceType "return" Expr
[70 (Formal)]    | FormalDefaultCaseClause |    ::=    | "default" "$" VarName "return" Expr

The following judgments

statEnv |-  Type₁ case FormalCaseClause : Type

statEnv |-  Type₁ case FormalDefaultCaseClause : Type

is used in the static semantics of typeswitch. It indicates that under the static environment statEnv, and with the input type of the typeswitch being Type₁, the given case clause yields the type Type.

The following judgment

dynEnv |-  Value₁ against FormalCaseClauses => Value₂

is used in the dynamic semantics of typeswitch. It indicates that under the dynamic environment dynEnv, with the input value of the typeswitch being Value₁, the given case clauses yield the value Value₂.

Static Type Analysis

The static typing rules for the typeswitch expression are simple. Each case clause and the default clause of the typeswitch is typed independently. The type of the entire typeswitch expression is the union of the types of all the clauses.

statEnv |-  Expr₀ : Type₀

statEnv |-  Type₀ case case $VarName₁ as SequenceType₁ return Expr₁ : Type₁

    ···

statEnv |-  Type₀ case case $VarNamen as SequenceTypen return Exprn : Typen

statEnv |-  Type₀ case default $VarNamen+1 return Exprn : Typen+1

statEnv |- 

(typeswitch (Expr₀)

  case $VarName₁ as SequenceType₁ return Expr₁

    ···

  case $VarNamen as SequenceTypen return Exprn

  default $VarNamen+1 return Exprn+1)

: (Type₁ | ... | Typen+1)

To type one case clause, the case variable is assigned the type of the case clause CaseType and the body of the clause is typed in the extended environment. Thus, the type of a case clause is independent of the type of the input expression.

CaseType = [ SequenceType ]sequencetype

statEnv |-  VarName of var expands to Variable

statEnv + varType(Variable => CaseType )  |-  Expr : Type

statEnv |-  Type₀ case case $VarName as SequenceType return Expr : Type

To type the default clause, the variable is assigned the type of the input expression and the body of the default clause is typed in the extended environment.

statEnv |-  VarName of var expands to Variable

statEnv + varType(Variable => Type₀ )  |-  Expr : Type

statEnv |-  Type₀ case default $VarName return Expr : Type

Dynamic Evaluation

The evaluation of a typeswitch proceeds as follows. First, the input expression is evaluated, yielding an input value. The effective case is the first case clause such that the input value matches the SequenceType in the case clause. The return clause of the effective case is evaluated and the value of the return expression is the value of the typeswitch expression.

dynEnv |-  Expr => Value₀

dynEnv |-  Value₀ against FormalCaseClauses => Value₁

dynEnv |-  typeswitch (Expr) FormalCaseClauses => Value₁

If the value matches the sequence type, the following rule applies: It extends the dynamic environment by binding the variable Variable to Value₀ and evaluates the body of the return clause.

CaseType = [ SequenceType ]sequencetype

statEnv  |-  Value₀ matches CaseType

statEnv  |-  VarName of var expands to Variable

dynEnv + varValue(Variable => Value₀)  |-  Expr => Value₁

dynEnv |-  Value₀ against case $VarName as SequenceType return Expr FormalCaseClauses => Value₁

If the value does not match the sequence type, the current case is not evaluated, and the remaining case clauses are evaluated in order by applying the inference rule recursively.

CaseType = [ SequenceType ]sequencetype      statEnv  |-  not(Value₀ matches CaseType)      dynEnv |-  Value₀ against FormalCaseClauses => Value₁

dynEnv |-  Value₀ against case $VarName as SequenceType return Expr FormalCaseClauses => Value₁

The last rule states that the default branch of a typeswitch expression always evaluates to the value of its return clause.

statEnv  |-  VarName of var expands to Variable

dynEnv + varValue(Variable => Value₀)  |-  Expr => Value₁

dynEnv |-  Value₀ against default $VarName return Expr => Value₁

4.12.3 Cast

Introduction

The cast expression can be used to convert a value to a specific datatype. It changes both the type and value of the result of an expression, and can only be applied to an atomic value.

[57 (XQuery)]    | CastExpr XQ |    ::=    | UnaryExpr ( "cast" "as" SingleType )?
[117 (XQuery)]    | SingleType XQ |    ::=    | AtomicType "?"?

Core Grammar

The Core grammar productions for cast expressions are:

[39 (Core)]    | CastExpr |    ::=    | ValueExpr ( "cast" "as" SingleType )?
[74 (Core)]    | SingleType |    ::=    | AtomicType "?"?

Normalization

The normalization of cast applies atomization to its argument. The type declaration asserts that the result is a single atomic value. The second normalization rule applies when the target type is optional.

[Expr cast as AtomicType ]Expr

==

let $v as xs:anyAtomicType := fn:data(([ Expr ]Expr)) return

  $v cast as AtomicType

[Expr cast as AtomicType? ]Expr

==

let $v as xs:anyAtomicType? := fn:data(([ Expr ]Expr)) return

  typeswitch ($v)

    case $fs:new as empty-sequence() return ()

    default $fs:new return $v cast as AtomicType

Static Type Analysis

The static typing rule of cast expression is as follows. The type of a Core cast expression is always the target type. Note that a cast expression can fail at run-time if the given value cannot be cast to the target type.

statEnv |-  Expr cast as AtomicType : AtomicType

Notation

The dynamic semantics of cast expressions is defined in Section 17 CastingFO. The semantics of cast expressions depends on the type of the input value and on the target type. For any source and target primitive types, the casting table in Section 17 CastingFO indicates whether the cast from the source type to the target type is permitted. When a cast is permitted, the detailed dynamic evaluation rules for cast in Section 17 CastingFO are applied. We refer to those rules using an auxiliary judgment defined as follows.

The judgment

AtomicValue₁ cast value to type AtomicType => AtomicValue₂

holds if AtomicValue₁ can be cast to type AtomicType, resulting in the new value AtomicValue₂ according to the rules in Section 17 CastingFO.

Dynamic Evaluation

dynEnv |-  Expr => AtomicValue₁

AtomicValue₁ cast value to type AtomicType => AtomicValue₂

dynEnv |-  Expr cast as AtomicType => AtomicValue₂

4.12.4 Castable

[56 (XQuery)]   
CastableExpr XQ
   ::=   
CastExpr ( "castable" "as" SingleType )?

Castable expressions check whether a value can be cast to a given type.

Core Grammar

The Core grammar production for castable is:

[38 (Core)]   
CastableExpr
   ::=   
CastExpr ( "castable" "as" SingleType )?

Normalization

The normalization of castable simply maps its expression argument.

[Expr castable as AtomicType]Expr

==

let $v as xs:anyAtomicType := fn:data(([ Expr ]Expr)) return

$v castable as AtomicType

[Expr castable as AtomicType?]Expr

==

let $v as xs:anyAtomicType? := fn:data(([ Expr ]Expr)) return

$v castable as AtomicType?

Static Type Analysis

The type of a Core castable expression is always a boolean.

statEnv |-  Expr castable as AtomicType : xs:boolean

Dynamic Evaluation

If casting succeeds, then the castable expression evaluates to true.

dynEnv |-  Expr cast as AtomicType => Value₂

dynEnv |-  Expr castable as AtomicType => true

Otherwise, 'castable as' evaluates to false.

dynEnv |-  not(Expr => Value₁)

dynEnv |-  Expr₁ castable as AtomicType₂ => false

4.12.5 Constructor Functions

Constructor functions provide an alternative syntax for casting.

Normalization

Constructor functions for atomic types are normalized to explicit cast as expressions. Note that the following normalization rule requires to resolve the name of the function call and checks whether than name stands for an atomic type in the static context.

statEnv |-  QName of func expands to expanded-QName

statEnv.typeDefn(expanded-QName) = define type QName₂ AtomicTypeDerivation

statEnv |-  [QName(ExprSingle₁)]Expr = [ExprSingle₁ cast as QName?]Expr

4.12.6 Treat

[55 (XQuery)]   
TreatExpr XQ
   ::=   
CastableExpr ( "treat" "as" SequenceType )?

Introduction

The expression "Expr treat as SequenceType", can be used to change the static type of the result of an expression without changing its value. The treat-as expression raises a dynamic error if the dynamic type of the input value does not match the specified type.

Normalization

Treat as expressions are normalized to typeswitch expressions. Note that the following normalization rule uses a variable $fs:new, which is a newly created variable that does not conflict with any variables already in scope.

[Expr treat as SequenceType]Expr

==

typeswitch ([ Expr ]Expr)

  case $fs:new as SequenceType return $fs:new

  default $fs:new return fn:error()

4.13 Validate Expressions

[63 (XQuery)]    | ValidateExpr XQ |    ::=    | "validate" ValidationMode? "{" Expr "}"
[64 (XQuery)]    | ValidationMode XQ |    ::=    | "lax" | "strict"

Core Grammar

The Core grammar productions for validate are:

[41 (Core)]    | ValidateExpr |    ::=    | "validate" ValidationMode? "{" Expr "}"
[42 (Core)]    | ValidationMode |    ::=    | "lax" | "strict"

A validate expression validates its argument with respect to the in-scope schema definitions, using the schema validation process described in [Schema Part 1]. The argument to a validate expression must be either an element or a document node. Validation replaces all nodes with new nodes that have their own identity, the type annotationXQ, and default values created during the validation process.

Normalization

A validate expression with no validation mode is normalized into a validate expression with the validation mode set to strict.

[validate { Expr }]Expr

==

validate strict { [Expr]Expr }

[validate ValidationMode { Expr }]Expr

==

validate ValidationMode { [Expr]Expr }

Static Type Analysis

Static typing of the validate operation is defined by the following rule. Note the use of a subtyping check to ensure that the type of the expression to validate is either an element or a well-formed document node (i.e., with only one root element and no text nodes). The type of the expression to validate may be a union of more than one element type. We apply the with mode judgment to each element type to determine the meaning of that element type with the given validation mode, which yields a new element type. The result type is the union over all new element types.

statEnv |-  Expr : Type

statEnv |-  Type <: (element | document { ElementType })

statEnv |-  prime(Type) = ElementType₁ | ... | ElementTypen

ElementType₁ = element ElementNameOrWildcard 1 OptTypeSpecifier 1

···

ElementTypen = element ElementNameOrWildcard n OptTypeSpecifier n

statEnv |-  ElementNameOrWildcard 1 with mode ValidationMode resolves to ElementType₁

···

statEnv |-  ElementNameOrWildcard n with mode ValidationMode resolves to ElementTypen

Type₁ = ElementType₁ | ... | ElementTypen

statEnv |-  validate ValidationMode { Expr } : Type₁

4.13.1 Validating an Element Node

Dynamic Evaluation

The normative dynamic semantics of validation is specified in Section 3.13 Validate ExpressionsXQ. The effect of validation of a data model value is equivalent to:

serialization of the data model, as described in [Data Model Serialization], followed by

validation of the serialized value into a Post-Schema Validated Infoset, as described in [Schema Part 1], followed by

construction of a new data model value, as described in [Data Model].

The above steps are expressed formally by the "erasure" and "annotation" judgments. Formally, validation removes existing type annotations from nodes ("erasure"), and it re-validates the corresponding data model instance, possibly adding new type annotations to nodes ("annotation"). Both erasure and annotation are described formally in [F Auxiliary Judgments for Validation]. Indeed, the conjunction of erasure and annotation provides a formal model for a large part of actual schema validation. The semantics of the validate expression is specified as follows.

In the first premise below, the expression to validate is evaluated. The resulting value must be an element or document node. The second premise constructs a new value in which all existing type annotations have been erased. The third premise determines the element type that corresponds to the element node's name in the given validation mode. The last premise validates erased element node with the type against which it is validated, using the annotate as judgment, yielding the final validated element.

statEnv; dynEnv  |-  Expr => ElementValue₁

ElementValue₁ erases to ElementValue₂

ElementValue₂ = element ElementName₂ of type TypeName₂ { Value }

statEnv |-  ElementName₂ with mode ValidationMode resolves to ElementType₂

statEnv |-  annotate as ElementType₂ ( ElementValue₂) => ElementValue₃

dynEnv |-  validate ValidationMode { Expr } => ElementValue₃

4.13.2 Validating a Document Node

The rule for validating a document node is similar to that for validating an element node.

Dynamic Evaluation

statEnv; dynEnv  |-  Expr => document { ElementValue₁ }

document { ElementValue₁ } erases to document { ElementValue₂ }

ElementValue₂ = element ElementName₂ of type TypeName₂ { Value }

statEnv |-  ElementName₂ with mode ValidationMode resolves to ElementType₂

statEnv |-  annotate as document { ElementType₂ } (document { ElementValue₂ }) => document { ElementValue₃ }

dynEnv |-  validate ValidationMode { Expr } => document { ElementValue₃ }

4.14 Extension Expressions

Introduction

An extension expression is an expression whose semantics are implementation-defined. An extension expression consists of one or more pragmas, followed by an expression enclosed in curly braces.

[65 (XQuery)]    | ExtensionExprXQ |    ::=    | Pragma+ "{" Expr? "}"
[66 (XQuery)]    | PragmaXQ |    ::=    | "(#" S? QName (S PragmaContents)? "#)"
[67 (XQuery)]    | PragmaContentsXQ |    ::=    | (Char* - (Char* '#)' Char*))

Core Grammar

The Core grammar productions for ExtensionExpr are:

[43 (Core)]    | ExtensionExpr |    ::=    | Pragma+ "{" Expr? "}"
[44 (Core)]    | Pragma |    ::=    | "(#" S? QName (S PragmaContents)? "#)"
[45 (Core)]    | PragmaContents |    ::=    | (Char* - (Char* '#)' Char*))

Normalization

Extension expressions are normalized as extension expressions in the [XPath/XQuery] Core.

[Pragma+ { Expr }]Expr

==

Pragma+ { [Expr]Expr }

If the extension expression does not contain any expression, this is normalized into an extension expression with a call to the fn:error function.

[Pragma+ { }]Expr

==

Pragma+ { fn:error() }

Static Type Analysis

If at least one of the pragmas is recognized, the static semantics are implementation-defined.

If none of the pragmas is recognized, the static semantics are the same as for the input expression. In both cases, the static typing must be applied on the input expression, possibly raising the corresponding type errors.

statEnv |-  Expr : Type₁

statEnv |-  A Pragma is recognized, yielding the implementation-defined static type Type₂.

statEnv |-  Pragma+ { Expr } : Type₂

statEnv |-  Expr : Type₁

statEnv |-  No Pragma is recognized.

statEnv |-  Pragma+ { Expr } : Type₁

Dynamic Evaluation

The QName of a pragma must resolve to a namespace URI and local name, using the statically known namespaces. If at least one of the pragmas is recognized, the dynamic semantics is implementation-defined.

dynEnv |-  Some Pragma are recognized, yielding the implementation-defined value Value.

dynEnv |-  Pragma+ { Expr } => Value

If none of the pragmas is recognized, the dynamic semantics of an ExtensionExpr are the same as evaluating the given expression.

No Pragma is recognized.      dynEnv |-  Expr => Value

dynEnv |-  Pragma+ { Expr } => Value

5 Modules and Prologs

The organization of this section parallels the organization of Section 4 Modules and PrologsXQ.

Introduction

XQuery supports modules as defined in Section 4 Modules and PrologsXQ. A main moduleXQ contains a PrologXQ followed by a query bodyXQ. A query has exactly one main module. In a main module, the query bodyXQ can be evaluated, and its value is the result of the query. A library moduleXQ contains a module declaration followed by a PrologXQ.

The Prolog is a sequence of declarations that affect query processing. The Prolog can be used, for example, to declare namespace prefixes, import types from XML Schemas, and declare functions and variables. Namespace declarations and schema imports always precede function and variable declarations, as specified by the following grammar productions.

Query Module

[1 (XQuery)]    | Module XQ |    ::=    | VersionDecl? (LibraryModule | MainModule)
[3 (XQuery)]    | MainModule XQ |    ::=    | Prolog QueryBody
[4 (XQuery)]    | LibraryModule XQ |    ::=    | ModuleDecl Prolog
[6 (XQuery)]    | Prolog XQ |    ::=    | ((DefaultNamespaceDecl | Setter | NamespaceDecl | Import) Separator)* ((VarDecl | FunctionDecl | OptionDecl) Separator)*
[7 (XQuery)]    | Setter XQ |    ::=    | BoundarySpaceDecl | DefaultCollationDecl | BaseURIDecl | ConstructionDecl | OrderingModeDecl | EmptyOrderDecl | CopyNamespacesDecl
[8 (XQuery)]    | Import XQ |    ::=    | SchemaImport | ModuleImport
[9 (XQuery)]    | Separator XQ |    ::=    | ";"
[30 (XQuery)]    | QueryBody XQ |    ::=    | Expr

Function declarations are globally scoped, that is, the use of a function name in a function call may precede declaration of the function. Variable declarations are lexically scoped, i.e., variable declarations must precede variable uses.

Core Grammar

The module declarations and prolog are processed as part of the static and dynamic context processing. In addition, normalization of prolog declarations is performed into a simplified formal grammar given below. As a result, the XQuery core does not need to include the prolog and module declarations. The entry point for the core grammar is the Expr non-terminal, as given in [4 Expressions].

Notation

Modules are identified and can be imported using a target namespace (a URI). In [XPath/XQuery], the process by which a module is obtained from a given target namespace is implementation defined. In this specification, we use the following auxiliary judgment to model that implementation defined process.

The judgment:

AnyURI is target namespace of modules Module₁ ... Modulen

holds if Module₁ ... Modulen are the modules associated to the target namespace AnyURI, and such as Modulei does not depend directly, or transitively on any module after it. (See [XQuery 1.0: An XML Query Language] for the formal definition of whether a module directly depends on another)

Notation

The XQuery Prolog requires that declarations appear in a particular order. In the Formal Semantics, it is simpler to assume the declarations can appear in any order, as it does not change their semantics -- we simply assume that an XQuery parser has enforced the required order.

The Prolog contains a variety of declarations that specify the initial static and dynamic context of the query. The following formal grammar productions represent any Prolog declaration.

Prolog Declarations

[71 (Formal)]   
PrologDeclList
   ::=   
(PrologDecl Separator PrologDeclList)?

[72 (Formal)]   
PrologDecl
   ::=   
DefaultCollationDecl
| BaseURIDecl
| ConstructionDecl
| OrderingModeDecl
| EmptyOrderDecl
| CopyNamespacesDecl
| SchemaImport
| ModuleImport
| NamespaceDecl
| DefaultNamespaceDecl
| VarDecl
| FunctionDecl
| OptionDecl

The function []PrologDecl takes a prolog declaration and maps it into its equivalent declaration in the Core grammar.

[PrologDecl₁]PrologDecl

==

PrologDecl₂

The following auxiliary judgments are applied when statically processing the declarations in the prolog. The effect of the judgment is to process each prolog declaration in order, constructing a new static environment from the static environment constructed from previous prolog declarations.

The judgment:

AnyURI ; statEnv₁ |-  PrologDeclList =>stat statEnv₂ with PrologDeclList₁

holds if for the given module with namespace AnyURI, and under the static environment statEnv₁, the sequence of prolog declarations PrologDeclList yields the static environment statEnv₂ and the normalized sequence of prolog declarations in the Core grammar.

The judgment:

statEnv₁ |-  PrologDecl =>stat statEnv₂

holds if under the static environment statEnv₁, the single prolog declaration PrologDecl yields the new static environment statEnv₂.

Notation

Because functions can be mutually referential, function signatures must be defined in the static environment before static type analysis is applied to the function bodies. The following judgment is used to extend the static environment with the appropriate function signatures. That judgment is used when computing the static context for a given module before applying static context processing.

The judgment:

statEnv₁ |-  PrologDeclList =>sigs statEnv₂

holds if extending the static environment statEnv₁ with the function signatures declared in PrologDeclList yields the new static environment statEnv₂.

This judgment is defined as follows. In case there is no declaration, the static environment is returned unchanged.

statEnv |-  =>sigs statEnv

If the case of a namespace declaration, the static context is extended with the corresponding namespace binding.

PrologDecl = NamespaceDecl or PrologDecl = DefaultNamespaceDecl

statEnv |-  PrologDecl =>stat statEnv₁

statEnv₁ |-  PrologDeclList =>sigs statEnv₂

statEnv |-  PrologDecl ; PrologDeclList =>sigs statEnv₂

If the case of a function declaration, the static context is extended with the corresponding signature.

PrologDecl = FunctionDecl

statEnv |-  PrologDecl =>sigs statEnv₁

statEnv₁ |-  PrologDeclList =>sigs statEnv₂

statEnv |-  PrologDecl ; PrologDeclList =>sigs statEnv₂

FunctionDecl = declare function QName ( $VarName₁ as SequenceType₁, ..., $VarNamen as SequenceTypen) as SequenceTyper (EnclosedExpr | external)

statEnv |-  QName of func expands to expanded-QName

[SequenceType₁]sequencetype = Type₁

...

[SequenceTypen]sequencetype = Typen

[SequenceTyper]sequencetype = Typer

FunctionSig = declare function expanded-QName(Type₁, ..., Typen) as Typer

statEnv₁ = statEnv + funcType(expanded-QName => FunctionSig)

statEnv |-  FunctionDecl =>sigs statEnv₁

For all other kinds of declarations, the static context is left unchanged.

not(PrologDecl = FunctionDecl) and not(PrologDecl = NamespaceDecl) and not(PrologDecl = DefaultNamespaceDecl)

statEnv |-  PrologDecl ; PrologDeclList =>sigs statEnv

In case of a function declaration, the static context is extended with the corresponding function signature.

Static Context Processing

Prolog declarations are processed in the order they are encountered. The normalization of a prolog declaration PrologDecl depends on the static context processing of all previous prolog declarations. In turn, static context processing of PrologDecl depends on the normalization of the PrologDecl. For example, because variables are lexically scoped, the normalization and static context processing of a variable declaration depends on the normalization and static context processing of all previous variable declarations. Therefore, the normalization phase and static context processing are interleaved, with normalization preceding static context processing for each prolog declaration.

The following inference rules express this dependency. The first rule specifies that for an empty sequence of prolog declarations, the initial static environment is left unchanged.

AnyURI ; statEnv |-  =>stat statEnv with

The next two rules interleaves normalization and static context processing. The result of static context processing and normalization is a static context and the normalized prolog declarations. In case the declaration is a module import, the URI for the current module is passed to the static context processing rule. This allows to avoid self-import, which is handled globally (See rules for building the context for module declarations in [5.2 Module Declaration]).

not(PrologDecl = ModuleImport)

[PrologDecl]PrologDecl == PrologDecl₁

statEnv |-  PrologDecl₁ =>stat statEnv₁

AnyURI ; statEnv₁ |-  PrologDeclList =>stat statEnv₂ with PrologDeclList₁

AnyURI ; statEnv |-  PrologDecl ; PrologDeclList =>stat statEnv₂ with PrologDecl₁ ; PrologDeclList₁

PrologDecl = ModuleImport

[PrologDecl]PrologDecl == PrologDecl₁

AnyURI ; statEnv |-  PrologDecl₁ =>stat statEnv₁

AnyURI ; statEnv₁ |-  PrologDeclList =>stat statEnv₂ with PrologDeclList₁

AnyURI ; statEnv |-  PrologDecl ; PrologDeclList =>stat statEnv₂ with PrologDecl₁ ; PrologDeclList₁

Static Type Analysis

Static typing of a main module follows context processing and normalization. Context processing and normalization of a main module applies the rules above to the prolog, then using the resulting static environment statEnv, the query body is normalized into a Core expression, and the static typing rules are applied to this Core expression.

AnyURI ; statEnvDefault |-  PrologDeclList =>stat statEnv with PrologDeclList₁

statEnv |-  [QueryBody]Expr == Expr₂

statEnv |-  Expr₂ : Type

PrologDeclList QueryBody : Type

Notation

Similarly, the judgment:

dynEnv₁ |-  PrologDeclList =>dyn dynEnv₂

holds if under the dynamic environment dynEnv₁, the sequence of prolog declarations PrologDeclList yields the dynamic environment dynEnv₂.

The judgment:

dynEnv |-  PrologDecl =>dyn dynEnv₁

holds if under the dynamic environment dynEnv, the single prolog declaration PrologDecl yields the new dynamic environment dynEnv₁.

Dynamic Context Processing

The rules for initializing the dynamic context are as follows. The first rule specifies that for an empty sequence of prolog declarations, the dynamic environment is left unchanged.

dynEnv |-  =>dyn dynEnv

The second rule simply computes the dynamic environment by processing the prolog declarations in order.

dynEnv |-  PrologDecl =>dyn dynEnv₁

dynEnv₁ |-  PrologDeclList =>dyn dynEnv₂

dynEnv |-  PrologDecl ; PrologDeclList =>dyn dynEnv₂

Dynamic Evaluation

Dynamic evaluation of a main module applies the rules for dynamic-context processing to the prolog declarations, then using the resulting dynamic environment dynEnv, the dynamic evaluation rules are applied to the normalized query body.

dynEnvDefault |-  PrologDeclList =>dyn dynEnv

statEnvDefault |-  PrologDeclList =>stat statEnv₁

statEnv |-  [QueryBody]Expr == Expr₂

dynEnv |-  Expr₂ => Value

PrologDeclList QueryBody => Value

Notation

We define a new judgment that maps a module's target namespace (or a main module) to the corresponding module's static environment:

(AnyURI | #MAIN) =>module_statEnv statEnv

We also define a new judgment that maps a module's target namespace (or a main module) to the corresponding module's dynamic environment:

(AnyURI | #MAIN) =>module_dynEnv dynEnv

For a main module, those judgments are defined as follows.

statEnvDefault |-  PrologDeclList =>stat statEnv

#MAIN =>module_statEnv statEnv

dynEnvDefault |-  PrologDeclList =>dyn dynEnv

#MAIN =>module_dynEnv dynEnv

For a library module, those judgments are defined in [5.11 Module Import].

5.1 Version Declaration

[2 (XQuery)]   
VersionDecl XQ
   ::=   
"xquery" "version" StringLiteral ("encoding" StringLiteral)? Separator

Introduction

A version declaration specifies the applicable XQuery syntax and semantics for a module. An XQuery implementation must raise a static error when processing a query labeled with a version that the implementation does not support. This document applies to XQuery 1.0 only and does not specify this static error formally. Verifying whether the proper version declaration is used is not formally specified.

5.2 Module Declaration

Introduction

[5 (XQuery)]   
ModuleDecl XQ
   ::=   
"module" "namespace" NCName "=" URILiteral Separator

We assume that the static-context processing and dynamic-context processing described in [5 Modules and Prologs] are applied to all library modules before the normalization, static context processing, and dynamic context processing of the main module. That is, at the time an "import module" declaration is processed, we assume that the static and dynamic context of the imported module is already available. This assumption does not require or assume separate compilation of modules. An implementation might process all or some imported modules statically (i.e., before the importing module is identified) or dynamically (i.e., when the importing module is identified and processed).

Core Grammar

The core grammar production for module declarations is:

[1 (Core)]    | ModuleDecl |    ::=    | "module" "namespace" NCName "=" URILiteral Separator
[2 (Core)]    | Separator |    ::=    | ";"

Normalization

Module declarations are left unchanged through normalization.

[ModuleDecl]PrologDecl

==

ModuleDecl

Static Context Processing

The effect of a module declaration is to apply the static context processing rules defined in [5 Modules and Prologs] to the module's prolog. The resulting static context is then available to any importing module.

The module declaration extends the prolog with a namespace declaration that binds the module's prefix to its target namespace (a URI), then computes the static context for the complete module.

AnyURI is target namespace of modules Module₁ ... Modulen

Module₁ = module namespace NCName₁ = URILiteral; PrologDeclList₁

...

Module₁ = module namespace NCName₁ = URILiteral; PrologDeclListn

dynEnv |-  URILiteral has atomic value AnyURI

statEnvDefault |-  PrologDeclList₁ ... PrologDeclListn =>sigs statEnv₀

AnyURI ; statEnv₀ |-  declare namespace NCName = URILiteral; PrologDeclList₁ =>stat statEnv₁ with PrologDeclList

...

AnyURI ; statEnvn-1 |-  declare namespace NCName = URILiteral; PrologDeclListn =>stat statEnvn with PrologDeclList

AnyURI =>module_statEnv statEnvn

Note that the rule above and the rules for static context processing of an "import module" declaration in [5.11 Module Import] are mutually recursive.

Dynamic Context Processing

The dynamic context processing of a module declaration is similar to that of static processing. The module declaration extends the prolog with a namespace declaration that binds the module's prefix to its target namespace (a URI), then computes the dynamic context for the complete module.

AnyURI is target namespace of modules Module₁ ... Modulen

Module₁ = module namespace NCName = URILiteral; PrologDeclList₁

...

Modulen = module namespace NCName = URILiteral; PrologDeclListn

dynEnv |-  URILiteral has atomic value AnyURI

dynEnvDefault |-  declare namespace NCName = URILiteral; PrologDeclList₁ =>dyn dynEnv₁

...

dynEnvn-1 |-  declare namespace NCName = URILiteral; PrologDeclListn =>dyn dynEnvn

AnyURI =>module_dynEnv dynEnvn

Note that the rule above and the rules for dynamic context processing of an "import module" declaration in [5.11 Module Import] are mutually recursive.

5.3 Boundary-space Declaration

[11 (XQuery)]   
BoundarySpaceDecl XQ
   ::=   
"declare" "boundary-space" ("preserve" | "strip")

The semantics of a boundary-space declaration is not specified formally.

5.4 Default Collation Declaration

[19 (XQuery)]   
DefaultCollationDecl XQ
   ::=   
"declare" "default" "collation" URILiteral

Core Grammar

The core grammar production for default collation declarations is:

[11 (Core)]   
DefaultCollationDecl
   ::=   
"declare" "default" "collation" URILiteral

Normalization

Default collation declarations are left unchanged through normalization.

[DefaultCollationDecl]PrologDecl

==

DefaultCollationDecl

Static Context Processing

The default collation declaration updates the collations environment component within the static environment. The collations environment component is used by several functions in [Functions and Operators], but is not used in the Formal Semantics.

dynEnv |-  URILiteral has atomic value AnyURI

statEnv.collations(AnyURI) = Collation

statEnv₁ = statEnv + defaultCollation(Collation)

statEnv |-  declare default collation URILiteral =>stat statEnv₁

Dynamic Context Processing

The default collation declaration does not affect the dynamic context.

dynEnv |-  declare default collation URILiteral =>dyn dynEnv

5.5 Base URI Declaration

[20 (XQuery)]   
BaseURIDecl XQ
   ::=   
"declare" "base-uri" URILiteral

Core Grammar

The core grammar production for base uri declarations is:

[12 (Core)]   
BaseURIDecl
   ::=   
"declare" "base-uri" URILiteral

Normalization

Base URI declarations are left unchanged through normalization.

[BaseURIDecl]PrologDecl

==

BaseURIDecl

Static Context Processing

A base URI declaration specifies the base URI property of the static context, which is used when resolving relative URIs within a module.

dynEnv |-  URILiteral has atomic value AnyURI

statEnv₁ = statEnv + baseURI(AnyURI)

statEnv |-  declare base-uri URILiteral =>stat statEnv₁

Dynamic Context Processing

The base URI declaration does not affect the dynamic context.

dynEnv |-  declare base-uri URILiteral =>dyn dynEnv

5.6 Construction Declaration

[25 (XQuery)]   
ConstructionDecl XQ
   ::=   
"declare" "construction" ("strip" | "preserve")

Core Grammar

The core grammar production for construction declarations is:

[17 (Core)]   
ConstructionDecl
   ::=   
"declare" "construction" ("strip" | "preserve")

Notation

For convenience, we introduce the following auxiliary grammar production.

Constr Mode

[89 (Formal)]   
ConstructionMode
   ::=   
"preserve" | "strip"

Normalization

Construction declarations are left unchanged through normalization.

[ConstructionDecl]PrologDecl

==

ConstructionDecl

Static Context Processing

The construction declaration modifies the construction mode in the static context.

statEnv₁ = statEnv + constructionMode( ConstructionMode)

statEnv |-  declare construction ConstructionMode =>stat statEnv₁

Dynamic Context Processing

The construction declaration does not have any effect on the dynamic context.

dynEnv |-  declare construction ConstructionMode =>stat dynEnv

5.7 Ordering Mode Declaration

[14 (XQuery)]   
OrderingModeDecl XQ
   ::=   
"declare" "ordering" ("ordered" | "unordered")

Core Grammar

The core grammar production for ordering mode declarations is:

[6 (Core)]   
OrderingModeDecl
   ::=   
"declare" "ordering" ("ordered" | "unordered")

Normalization

Ordering mode declarations are left unchanged through normalization.

[OrderingModeDecl]PrologDecl

==

OrderingModeDecl

Static Context Processing

The ordering mode declaration does not have any effect on the static context.

statEnv |-  OrderingModeDecl =>stat statEnv

Dynamic Context Processing

The ordering mode declaration does not have any effect on the dynamic context.

dynEnv |-  OrderingModeDecl =>dyn dynEnv

5.8 Empty Order Declaration

[15 (XQuery)]   
EmptyOrderDecl XQ
   ::=   
"declare" "default" "order" "empty" ("greatest" | "least")

Core Grammar

The core grammar production for empty order declarations is:

[7 (Core)]   
EmptyOrderDecl
   ::=   
"declare" "default" "order" "empty" ("greatest" | "least")

Normalization

Empty order declarations are left unchanged through normalization.

[EmptyOrderDecl]PrologDecl

==

EmptyOrderDecl

Static Context Processing

The empty order declaration does not have any effect on the static context.

statEnv |-  EmptyOrderDecl =>stat statEnv

Dynamic Context Processing

The empty order declaration does not have any effect on the dynamic context.

dynEnv |-  EmptyOrderDecl =>dyn dynEnv

5.9 Copy-Namespaces Declaration

[16 (XQuery)]    | CopyNamespacesDecl XQ |    ::=    | "declare" "copy-namespaces" PreserveMode "," InheritMode
[17 (XQuery)]    | PreserveMode XQ |    ::=    | "preserve" | "no-preserve"
[18 (XQuery)]    | InheritMode XQ |    ::=    | "inherit" | "no-inherit"

Core Grammar

The core grammar productions for copy-namespaces declarations are:

[8 (Core)]    | CopyNamespacesDecl |    ::=    | "declare" "copy-namespaces" PreserveMode "," InheritMode
[9 (Core)]    | PreserveMode |    ::=    | "preserve" | "no-preserve"
[10 (Core)]    | InheritMode |    ::=    | "inherit" | "no-inherit"

Normalization

Copy-namespace declarations are left unchanged through normalization.

[CopyNamespacesDecl]PrologDecl

==

CopyNamespacesDecl

Static Context Processing

The copy-namespace declaration does not have any effect on the static context.

statEnv |-  CopyNamespacesDecl =>stat statEnv

Dynamic Context Processing

The copy-namespace declaration does not have any effect on the dynamic context.

dynEnv |-  CopyNamespacesDecl =>dyn dynEnv

5.10 Schema Import

Schema Imports

[21 (XQuery)]    | SchemaImport XQ |    ::=    | "import" "schema" SchemaPrefix? URILiteral ("at" URILiteral ("," URILiteral)*)?
[22 (XQuery)]    | SchemaPrefix XQ |    ::=    | ("namespace" NCName "=") | ("default" "element" "namespace")

The semantics of Schema Import is described in terms of the [XPath/XQuery] type system. The process of converting an XML Schema into a sequence of type declarations is described in Section [D Importing Schemas]. This section describes how the resulting sequence of type declarations is added into the static context when the Prolog is processed.

Core Grammar

The Core grammar productions for schema imports are:

Schema Imports

[13 (Core)]    | SchemaImport |    ::=    | "import" "schema" SchemaPrefix? URILiteral ("at" URILiteral ("," URILiteral)*)?
[14 (Core)]    | SchemaPrefix |    ::=    | ("namespace" NCName "=") | ("default" "element" "namespace")

Normalization

Schema imports are left unchanged through normalization.

[SchemaImport]PrologDecl

==

SchemaImport

Notation

For convenience, we introduce the following auxiliary grammar productions.

Location Hints

[16 (Formal)]    | LocationHints |    ::=    | "at" URILiteral ("," URILiteral)*
[82 (Formal)]    | OptLocationHints |    ::=    | LocationHints?

Notation

The following auxiliary judgments are used when processing schema imports.

The judgment:

statEnv₁ |-  Definitions =>type statEnv₂

holds if under the static environment statEnv₁, the sequence of type definitions Definitions yields the new static environment statEnv₂.

The judgment:

statEnv₁ |-  Definition =>type statEnv₂

holds if under the static environment statEnv₁, the single definition Definition yields the new static environment statEnv₂.

Static Context Processing

A schema imported into a query is first mapped into the [XPath/XQuery] type system, which yields a sequence of XQuery type definitions. The rules for mapping the imported schema begin in [D.2 Schemas as a whole]. Each type definition in an imported schema is then added to the static environment.

Definitions = [schema URILiteral OptLocationHints]Schema

statEnv |-  Definitions =>type statEnv₁

statEnv |-  import schema URILiteral OptLocationHints =>stat statEnv₁

The schema import declaration may also assign an element/type namespace prefix to the URI of the imported schema, or assign the default element namespace to the URI of the imported schema.

Definitions = [schema URILiteral OptLocationHints]Schema

statEnv |-  Definitions =>type statEnv₁

dynEnv |-  URILiteral has atomic value AnyURI

statEnv₂ = statEnv₁ + namespace(NCName => (passive, AnyURI))

statEnv |-  import schema namespace NCName = URILiteral OptLocationHints =>stat statEnv₂

Definitions = [schema URILiteral OptLocationHints]Schema

statEnv |-  Definitions =>type statEnv₁

dynEnv |-  URILiteral has atomic value AnyURI

statEnv₂ = statEnv₁ + default_elem_namespace( AnyURI)

statEnv |-  import schema default element namespace URILiteral OptLocationHints =>stat statEnv₂

An empty sequence of type definitions yields the input environment.

statEnv |-  =>type statEnv

Each type definition is added into the static environment.

statEnv |-  Definitions =>type statEnv₁

statEnv₁ |-  Definition 1 =>type statEnv₂

statEnv |-  Definition 1 Definitions =>type statEnv₂

Each type, element, or attribute declaration is added respectively to the type, element and attribute declarations components of the static environment.

statEnv |-  TypeName of elem/type expands to expanded-QName

statEnv₁ = statEnv + typeDefn(expanded-QName => define type TypeName TypeDerivation )

statEnv |-  define type TypeName TypeDerivation =>type statEnv₁

statEnv |-  ElementName of elem/type expands to expanded-QName

statEnv₁ = statEnv + elemDecl(expanded-QName => define element ElementName OptSubstitution OptNillable TypeReference)

statEnv |-  define element ElementName OptSubstitution OptNillable TypeReference =>type statEnv₁

statEnv |-  AttributeName of attr expands to expanded-QName

statEnv₁ = statEnv + attrDecl(expanded-QName => define attribute AttributeName TypeReference)

statEnv |-  define attribute AttributeName TypeReference =>type statEnv₁

Note that it is a static error to import two schemas that both define the same name in the same symbol space and in the same scope. That is multiple top-level definitions of the same type, element, or attribute name raises a static error. For instance, a query may not import two schemas that include top-level element declarations for two elements with the same expanded name.

Dynamic Context Processing

The schema import declarations do not affect the dynamic context.

dynEnv |-  SchemaImport =>dyn dynEnv

5.11 Module Import

[23 (XQuery)]   
ModuleImport XQ
   ::=   
"import" "module" ("namespace" NCName "=")? URILiteral ("at" URILiteral ("," URILiteral)*)?

Introduction

The effect of an "import module" declaration is to extend the importing module's dynamic (and static) context with the global variables (and their types) and the functions (and their signatures) of the imported module. Module import is not transitive, only the global variables and functions declared explicitly in the imported module are available in the importing module. Also, module import does not import schemas, therefore the importing module must explicitly import any schemas on which the imported global variables or functions depend.

Core Grammar

The core grammar production for module imports is:

Module Import

[15 (Core)]   
ModuleImport
   ::=   
"import" "module" ("namespace" NCName "=")? URILiteral ("at" URILiteral ("," URILiteral)*)?

Normalization

Module imports are left unchanged through normalization.

[ModuleImport]PrologDecl

==

ModuleImport

Notation

The rules below depend on the following auxiliary functions which are used to import the proper fragment of the static context.

The function fs:local-variables(statEnv, AnyURI) returns all the (expanded-QName, Type) pairs in statEnv.varType such that the URI part of the variable's expanded-QName equals the given URI, that is, the variables that are declared locally in the module with the given namespace URI.

The function fs:local-functions(statEnv, AnyURI) returns all the function signatures in statEnv.funcType such that the URI part of the function's expanded-QName equals the given URI, that is, the function signatures that are declared locally in the module with the given namespace URI.

Notation

The following auxiliary judgments is used to extend a given static environment with the static environment from an imported module.

The judgment

statEnv₁ extended with static environment statEnv₂ yields statEnv₃ for uri AnyURI₁

holds if extending the environment statEnv₁ with the environment statEnv₂ yields the environment statEnv₃ under the given namespace uri AnyURI.

This judgment is defined as follows.

fs:local-variables(statEnv₂, AnyURI) = (Variable₁,Type₁) ... (Variablem,Typem)

statEnv₃ = statEnv₁ + varType(Variable₁ => Type₁ ... ; Variablem => Typem)

fs:local-functions(statEnv₂, AnyURI) = (expanded-QName₁,FunctionSig₁) ... (expanded-QNamen,FunctionSign)

statEnv₄ = statEnv₃ + funcType(expanded-QName₁ => FunctionSig₁; ... ;expanded-QNamen => FunctionSign)

statEnv₁ extended with static environment statEnv₂ yields statEnv₄ for uri AnyURI₁

Notation

The rules below depend on the following auxiliary judgments.

The following rules add each variable explicitly declared in the imported module to the importing module's dynamic variable environment.

dynEnv₁ ; AnyURI |-  =>import_variables dynEnv₁

dynEnv₂ = dynEnv₁ + varValue(expanded-QName₁ => #IMPORTED(AnyURI))

dynEnv₂ ; AnyURI |-  (expanded-QName₂, Type₂), ···, (expanded-QNamen, Typen) =>import_variables dynEnv₃

dynEnv₁ ; AnyURI |-  (expanded-QName₁, Type₁), ···, (expanded-QNamen, Typen) =>import_variables dynEnv₃

The following rules add each function explicitly declared in the imported module to the importing module's dynamic function environment.

dynEnv₁ ; AnyURI |-  =>import_functions dynEnv₁

dynEnv₂ = dynEnv₁ + funcDefn((expanded-QName₁(Type1,1, ..., Type1,n)) => #IMPORTED(AnyURI))

dynEnv₂ ; AnyURI |-  (expanded-QName₂(Type2,1, ..., Type2,n)), ···, (expanded-QNamek(Typek,1, ..., Typek,n)) =>import_functions dynEnv₃

dynEnv₁ ; AnyURI |-  (expanded-QName₁(Type1,1, ..., Type1,n)), ···, (expanded-QNamek(Typek,1, ..., Typek,n)) =>import_functions dynEnv₃

Notation

The following auxiliary judgments is used to extend a given dynamic environment with the dynamic environment from an imported module.

The judgment

dynEnv₁ extended with dynamic environment dynEnv₂ yields dynEnv₃ for uri AnyURI

holds if extending the dynamic environment dynEnv₁ with the dynamic environment dynEnv₂ yields the dynamic environment dynEnv₃ under the given namespace uri AnyURI.

This judgment is defined as follows.

dynEnv₁ ; AnyURI |-  fs:local-variables(statEnv₂, AnyURI) =>import_variables dynEnv₃

dynEnv₁ ; AnyURI |-  fs:local-variables(statEnv₂, AnyURI) =>import_variables dynEnv₃

dynEnv₃ ; AnyURI |-  fs:local-functions(statEnv₂, AnyURI) =>import_functions dynEnv₄

dynEnv₁ extended with dynamic environment dynEnv₂ yields dynEnv₄ for uri AnyURI

Static Context Processing

The first set of premises below "look up" the static contexts of all the imported modules, as defined in [5.2 Module Declaration]. The second set of premises extend the input static context with the global variables and function signatures declared in the imported static contexts.

not(AnyURI₁ = AnyURI)

AnyURI₁ =>module_statEnv statEnv₁

statEnv extended with static environment statEnv₁ yields statEnv₂ for uri AnyURI₁

AnyURI ; statEnv |-  import module AnyURI₁ LocationHints? =>stat statEnv₂

AnyURI₁ = AnyURI

AnyURI ; statEnv |-  import module AnyURI₁ LocationHints? =>stat statEnv₁

not(AnyURI₁ = AnyURI)

dynEnv |-  URILiteral₁ has atomic value AnyURI₁

AnyURI₁ =>module_statEnv statEnv₁

statEnv extended with static environment statEnv₁ yields statEnv₂ for uri AnyURI₁

statEnv₃ = statEnv₂ + namespace(NCName => (passive, AnyURI))

statEnv |-  import module namespace NCName = URILiteral₁ LocationHints? =>stat statEnv₃

AnyURI₁ = AnyURI

dynEnv |-  URILiteral₁ has atomic value AnyURI₁

statEnv₂ = statEnv₁ + namespace(NCName => (passive, AnyURI))

statEnv |-  import module namespace NCName = URILiteral₁ LocationHints? =>stat statEnv₂

Note that the rules above and the rules for processing a library module in [5.2 Module Declaration] above are mutually recursive. It is possible to define the semantics in that way, since XQuery forbids the use of recursive modules.

Dynamic Context Processing

During dynamic context processing, each variable and function name is mapped to the special value #IMPORTED(AnyURI) to indicate that the variable or function is defined in the imported module with the given URI.

The first set of premises below "look up" the dynamic contexts of all the imported modules, as defined in [5.2 Module Declaration]. The second set of premises extend the input dynamic context with the global variables and functions declared in the imported dynamic contexts.

dynEnv |-  URILiteral has atomic value AnyURI

AnyURI =>module_dynEnv dynEnv₁

...

AnyURI =>module_dynEnv dynEnvn

dynEnv extended with dynamic environment dynEnv₁ yields dynEnv₁' for uri AnyURI

...

dynEnvn-1 extended with dynamic environment dynEnvn yields dynEnvn' for uri AnyURI

dynEnv₁ |-  import module (namespace NCName =)? URILiteral LocationHints? =>dyn dynEnvn'

Note that the rule above and the rules for processing a library module in [5.2 Module Declaration] above are mutually recursive. It is possible to define the semantics in that way, since XQuery forbids the use of recursive modules.

5.12 Namespace Declaration

[10 (XQuery)]   
NamespaceDecl XQ
   ::=   
"declare" "namespace" NCName "=" URILiteral

Core Grammar

The core grammar production for namespace declarations is:

[3 (Core)]   
NamespaceDecl
   ::=   
"declare" "namespace" NCName "=" URILiteral

Normalization

Namespace declarations are left unchanged through normalization.

[NamespaceDecl]PrologDecl

==

NamespaceDecl

Static Context Processing

A namespace declaration adds a new (prefix,uri) binding in the namespace component of the static environment. All namespace declarations in the prolog are passive declarations. Namespace declaration attributes of element constructors are active declarations.

dynEnv |-  URILiteral has atomic value AnyURI

statEnv₁ = statEnv + namespace(NCName => (passive, AnyURI))

statEnv |-  declare namespace NCName = URILiteral =>stat statEnv₁

In case the URILiteral part of a namespace declaration is a zero-length string, the namespace prefix is marked as #UNDECLARED in the static context.

statEnv₁ = statEnv + namespace(NCName => (passive, #UNDECLARED))

statEnv |-  declare namespace NCName = "" =>stat statEnv₁

Dynamic Context Processing

The namespace declaration does not affect the dynamic context.

dynEnv |-  declare namespace NCName = URILiteral =>dyn dynEnv

5.13 Default Namespace Declaration

[12 (XQuery)]   
DefaultNamespaceDecl XQ
   ::=   
"declare" "default" ("element" | "function") "namespace" URILiteral

Core Grammar

The core grammar production for default namespace declarations is:

[4 (Core)]   
DefaultNamespaceDecl
   ::=   
"declare" "default" ("element" | "function") "namespace" URILiteral

Normalization

Default namespace declarations are left unchanged through normalization.

[DefaultNamespaceDecl]PrologDecl

==

DefaultNamespaceDecl

Static Context Processing

A default element namespace declaration changes the default element namespace component of the static environment. If the URI literal is the zero-length string, the default element namespace is set to the null namespace.

statEnv₁ = statEnv + default_elem_namespace(#NULL-NAMESPACE)

statEnv |-  declare default element namespace "" =>stat statEnv₁

not(URILiteral = "")

dynEnv |-  URILiteral has atomic value AnyURI

statEnv₁ = statEnv + default_elem_namespace( AnyURI)

statEnv |-  declare default element namespace URILiteral =>stat statEnv₁

A default function namespace declaration changes the default function namespace component of the static environment. If the URI literal is the zero-length string, the default function namespace is set to the null namespace.

statEnv₁ = statEnv + default_function_namespace(#NULL-NAMESPACE)

statEnv |-  declare default function namespace "" =>stat statEnv₁

not(URILiteral = "")

dynEnv |-  URILiteral has atomic value AnyURI

statEnv₁ = statEnv + default_function_namespace( AnyURI)

statEnv |-  declare default function namespace URILiteral =>stat statEnv₁

Note that multiple declarations of the same namespace prefix in the Prolog result in a static error. However, a declaration of a namespace in the Prolog can override a prefix that has been predeclared in the static context.

Dynamic Context Processing

Default namespace declarations do not affect the dynamic context.

dynEnv |-  DefaultNamespaceDecl =>dyn dynEnv

5.14 Variable Declaration

[24 (XQuery)]   
VarDecl XQ
   ::=   
"declare" "variable" "$" QName TypeDeclaration? ((":=" ExprSingle) | "external")

Core Grammar

The core grammar production for variable declarations is:

[16 (Core)]   
VarDecl
   ::=   
"declare" "variable" "$" QName TypeDeclaration? ((":=" ExprSingle) | "external")

Normalization

Normalization of a variable declaration normalizes its initializing expression, if it is present.

[ declare variable $VarName as SequenceType := Expr ]PrologDecl

==

declare variable $VarName as SequenceType := [Expr]Expr

[ declare variable $VarName := Expr ]PrologDecl

==

declare variable $VarName := [Expr]Expr

If an external variable declaration does not have a type declaration it is treated as if the type declaration was item()*.

[ declare variable $VarName external ]PrologDecl

==

declare variable $VarName as item()* external

[ declare variable $VarName as SequenceType external ]PrologDecl

==

declare variable $VarName as SequenceType external

Static Context Processing

A variable declaration updates the variable component of the static context by associating the given variable with a static type.

If a variable declaration has an associated expression but does not have a type declaration, the static type of the variable is the static type of the expression.

statEnv  |-  VarName of var expands to Variable

statEnv |-  Expr : Type

statEnv₁ = statEnv + varType( Variable => Type)

statEnv |-  declare variable $VarName := Expr =>stat statEnv₁

If the variable declaration has an associated expression and has a type declaration, the static type of the variable is the specified type. The type of the expression must be a subtype of the declared type.

statEnv  |-  VarName of var expands to Variable

Type = [SequenceType]sequencetype

statEnv |-  Expr : Type₂

statEnv |-  Type₂ <: Type

statEnv₁ = statEnv + varType( Variable => Type)

statEnv |-  declare variable $VarName as SequenceType := Expr =>stat statEnv₂

If the variable declaration is external and has a type declaration, the static type of the variable is the specified type.

statEnv  |-  VarName of var expands to Variable

Type = [SequenceType]sequencetype

statEnv₁ = statEnv + varType( Variable => Type)

statEnv |-  declare variable $VarName as SequenceType external =>stat statEnv₂

Dynamic Context Processing

To evaluate a variable declaration, its associated expression is evaluated, and the dynamic context is updated with the variable bound to the resulting value.

dynEnv |-  Expr => Value

statEnv  |-  VarName of var expands to Variable

dynEnv₁ = dynEnv + varValue( Variable => Value)

dynEnv |-  declare variable $VarName := Expr =>dyn dynEnv₁

dynEnv |-  Expr => Value

Type = [ SequenceType ]sequencetype

statEnv  |-  Value matches Type

statEnv  |-  VarName of var expands to Variable

dynEnv₁ = dynEnv + varValue( Variable => Value)

dynEnv |-  declare variable $VarName as SequenceType := Expr =>dyn dynEnv₁

Dynamic evaluation does not apply to externally defined variables. The dynamic environment must provide the values of external variables in the initial dynamic context (dynEnvDefault).

dynEnv |-  declare variable $VarName as SequenceType external =>dyn dynEnv

5.15 Function Declaration

Introduction

User-defined functions specify the name of the function, the names and types of the parameters, and the type of the result. The function body defines how the result of the function is computed from its parameters.

Function declarations

[26 (XQuery)]    | FunctionDecl XQ |    ::=    | "declare" "function" QName "(" ParamList? ")" ("as" SequenceType)? (EnclosedExpr | "external")
[27 (XQuery)]    | ParamList XQ |    ::=    | Param ("," Param)*
[28 (XQuery)]    | Param XQ |    ::=    | "$" QName TypeDeclaration?

Core Grammar

The core grammar productions for function declarations are:

Function declarations

[18 (Core)]    | FunctionDecl |    ::=    | "declare" "function" QName "(" ParamList? ")" ("as" SequenceType)? (EnclosedExpr | "external")
[19 (Core)]    | ParamList |    ::=    | Param ("," Param)*
[20 (Core)]    | Param |    ::=    | "$" QName TypeDeclaration?

Notation

The following auxiliary mapping rule is used for the normalization of parameters in function declarations: []Param.

Parameters without a declared type are given the item()* sequence type.

[$VarName]Param

==

$VarName as item()*

[$VarName as SequenceType ]Param

==

$VarName as SequenceType

An empty parameter list is left unchanged.

[]Param

==

A parameter list is normalized by applying the normalization rule to each parameter.

[ Param₁, ..., Paramn ]Param

==

[ Param₁ ]Param, ..., [ Paramn ]Param

Normalization

The parameter list and body of a user-defined function are all normalized into Core expressions.

statEnv |-  QName of func expands to expanded-QName

Type = [SequenceType]sequencetype

statEnv |-  [ declare function QName ( ParamList? ) as SequenceType { Expr } ]PrologDecl = declare function QName ( [ParamList?]Param ) as SequenceType { [Expr]FunctionArgument(Type) }

If the return type of the function is not provided, it is given the item()* sequence type.

[declare function QName ( ParamList? ) { Expr }]PrologDecl

==

[declare function QName ( ParamList? ) as item()* { Expr }]PrologDecl

Externally defined functions are normalized similarly.

[ declare function QName ( ParamList? ) as SequenceType external]PrologDecl

==

declare function QName( [ParamList?]Param ) as SequenceType external

[declare function QName ( ParamList? ) external ]PrologDecl

==

[declare function QName ( ParamList? ) as item()* external ]PrologDecl

Notation

We use the following auxiliary judgment during static context processing and static type analysis of function declarations.

The judgment:

statEnv |-  function declaration FunctionDecl with signature FunctionSig : Type

holds if the function declaration FunctionDecl with the signature FunctionSig has the type Type.

Static Context Processing

Static context processing accesses the function signature from the static context, and checks that the function declaration corresponds to the declared type.

statEnv.funcType(expanded-QName,n) = FunctionSig

statEnv |-  function declaration FunctionDecl with signature FunctionSig : Typer

statEnv |-  FunctionDecl =>stat statEnv₁

Note that the static context processing is performing type checking of the function, as defined below. Note also that the type checking is done in the new environment in which the function declaration has been added which ensures that recursive calls are type-checked properly.

Static Type Analysis

The static typing rules for function bodies follow normalization and processing of the static context. The static typing rules below construct a new environment in which each parameter has the given expected type, then the static type of the function's body is computed under the new environment. The function body's type must be a subtype of the expected return type. If static typing fails, a static type error is raised. Otherwise, static typing of the function has no other effect, as function signatures are already inside the static environment.

statEnv.varType |-  Expr : Type

statEnv |-  Type <: Typer

statEnv |-  function declaration declare function QName () as SequenceTyper { Expr } with signature declare function expanded-QName() as Typer : Typer

statEnv  |-  VarName₁ of var expands to Variable₁

...

statEnv  |-  VarNamen of var expands to Variablen

statEnv + varType( Variable₁ => Type₁ ;...; Variablen => Typen )  |-  Expr : Type

statEnv |-  Type can be promoted to Typer

statEnv |-  function declaration declare function QName ($VarName₁ as SequenceType₁, ···, $VarNamen as SequenceTypen) as SequenceTyper { Expr } with signature declare function expanded-QName(Type₁, ..., Typen) as Typer : Typer

The bodies of external functions are not available and therefore cannot by type checked. To ensure type soundness, the implementation must guarantee that the value returned by the external function matches the expected return type.

statEnv |-  function declaration declare function QName () as SequenceTyper external with signature declare function expanded-QName() as Typer : Typer

statEnv  |-  VarName₁ of var expands to Variable₁

...

statEnv  |-  VarNamen of var expands to Variablen

statEnv |-  function declaration declare function QName ( $VarName₁ as SequenceType₁, ···, $VarNamen as SequenceTypen ) as SequenceTyper external with signature declare function expanded-QName(Type₁, ..., Typen) as Typer : Typer

Dynamic Context Processing

A function declaration updates the dynamic context. The function name with arity N is associated with the given function body. The number of arguments is required, because XQuery permits overloading of function names as long as each function signature has a different number of arguments.

statEnv |-  QName of func expands to expanded-QName

dynEnv₁ = dynEnv + funcDefn(expanded-QName() => (Expr))

dynEnv |-  declare function QName () as SequenceTyper { Expr } =>dyn dynEnv₁

statEnv |-  QName of func expands to expanded-QName

statEnv |-  VarName₁ of var expands to Variable₁

···

statEnv  |-  VarNamen of var expands to Variablen

[SequenceType₁]sequencetype = Type₁

...

[SequenceTypen]sequencetype = Typen

dynEnv₁ = dynEnv + funcDefn(expanded-QName(Type₁,...,Typen) => ( Expr , Variable₁ , ···, Variablen))

dynEnv |-  declare function QName ( $VarName₁ as SequenceType₁, ···, $VarNamen as SequenceTypen ) as SequenceTyper { Expr } =>dyn dynEnv₁

An external function declaration does not affect the dynamic environment. The implementation must support the declared external functions.

dynEnv |-  declare function QName ( $VarName₁ as SequenceType₁, ···, $VarNamen as SequenceTypen ) as SequenceTyper external =>dyn dynEnv

The dynamic semantics of a function body are applied when the function is called, as described in [4.1.5 Function Calls].

5.16 Option Declaration

[13 (XQuery)]   
OptionDecl XQ
   ::=   
"declare" "option" QName StringLiteral

Core Grammar

The core grammar production for option declarations is:

[5 (Core)]   
OptionDecl
   ::=   
"declare" "option" QName StringLiteral

Normalization

Option declarations are left unchanged through normalization.

[OptionDecl]PrologDecl

==

OptionDecl

Static Context Processing

An option declaration does not have any effect on the static context.

statEnv |-  OptionDecl =>stat statEnv

Dynamic Context Processing

An option declaration does not have any effect on the dynamic context.

dynEnv |-  OptionDecl =>dyn dynEnv

6 Conformance

The XQuery Formal Semantics is intended primarily as a component that can be used by [XQuery 1.0: An XML Query Language], or a host language of [XML Path Language (XPath) 2.0]. Therefore, the XQuery Formal Semantics relies on specifications that use it (such as [XPath 2.0], [XSLT 2.0], and [XQuery]) to specify conformance criteria in their respective environments. Specifications that set conformance criteria for their use of the formal semantics must not relax the constraints expressed in this specification.

6.1 Static Typing Feature

This specification normatively defines the static typing feature which can be used in [XQuery 1.0: An XML Query Language] or a host language of [XML Path Language (XPath) 2.0]. The static typing feature is specified using the static typing judgment introduced in [3.2.3 Static typing judgment].

6.1.1 Static Typing Extensions

In some cases, the static typing rules are not very precise (see, for example, the type inference rules for the ancestor axes—parent, ancestor, and ancestor-or-self—and for the function fn:root). If an implementation supports a static typing extension, it must always provide a more precise type than the one defined in this specification.

This constraint is formally expressed as follows. A static typing extension Expr :ext Type must be such that for every expression Expr the following holds.

statEnv |-  Expr : Type

statEnv |-  Type' <: Type

statEnv |-  Expr :ext Type'

Note:

It is not recommended for a static typing extension to change the static typing behavior of expressions that specify a type explicitly (treat as, cast as, typeswitch, function parameters, and type declarations in variable bindings), since the purpose of those expressions is to impose a specific type.

7 Additional Semantics of Functions

This section defines the auxiliary functions required to define the formal semantics of [XPath/XQuery], and gives special normalization and static typing rules for some functions in [Functions and Operators].

Remember from [4.1.5 Function Calls] that the following rules operate after namespace resolution for the function name, and directly over the input type of the parameters. In the rest of the section, we will use the following shortcuts notations for specific relevant URIs:

FN-URI for functions from the [Functions and Operators] document.

OP-URI for operators from the [Functions and Operators] document.

FS-URI for formal semantics functions.

7.1 Formal Semantics Functions

Introduction

This section gives the definition and semantics of functions that are used in the formal semantics but are not in [Functions and Operators]. Their dynamic semantics are defined in the same informal style as in the [Functions and Operators] document. The static semantics of some formal-semantics functions require custom static typing rules.

7.1.1 The fs:convert-operand function

fs:convert-operand($actual as xs:anyAtomicType?, $expected as xs:anyAtomicType) as xs:anyAtomicType ?

The formal-semantics function fs:convert-operand converts the operands of arithmetic and comparison operators as follows:

If $actual is the empty sequence, returns the empty sequence.

If $actual is an instance of type xs:untypedAtomic, then

if $expected is an instance of type xs:untypedAtomic or xs:string, returns $actual cast to xs:string;

if $expected is of numeric type, returns $actual cast to xs:double

otherwise returns $actual cast to the type of $expected.

Otherwise, returns $actual.

Static Type Analysis

No conversion is needed unless $actual is an instance of type xs:untypedAtomic.

statEnv  |-  not(Type₁ <: xs:untypedAtomic?)

statEnv |-  (FS-URI,"convert-operand")( Type₁, Type₂) : Type₁

Pairs of untyped atomic operands are converted to strings.

statEnv |-  Type₁ <: xs:untypedAtomic ?

statEnv |-  Type₂ <: (xs:untypedAtomic| xs:string)

statEnv |-  (FS-URI,"convert-operand")( Type₁, Type₂) : xs:string · quantifier (Type₁)

When an untyped operand is paired with a numeric operand, it is converted to xs:double.

statEnv |-  Type₁ <: xs:untypedAtomic ?

statEnv |-  Type₂ <: fs:numeric

statEnv |-  (FS-URI,"convert-operand")( Type₁, Type₂) : xs:double · quantifier (Type₁)

Finally, an untyped atomic operand not dealt with by the above rules is converted to the type of the other operand.

statEnv |-  Type₁ <: xs:untypedAtomic ?

statEnv |-  Type₂ <: xs:anyAtomicType

statEnv  |-  not(Type₂ <: (xs:untypedAtomic| xs:string|fs:numeric))

statEnv |-  (FS-URI,"convert-operand")( Type₁, Type₂) : Type₂ · quantifier(Type₁)

7.1.2 The fs:convert-simple-operand function

fs:convert-simple-operand($actual as xs:anyAtomicType *, $expected as xs:anyAtomicType) as xs:anyAtomicTypeAtomic *

The formal-semantics function fs:convert-simple-operand is used to convert the value of the $actual argument such that it matches the type of the $expected argument (or matches a sequence of that type).

The dynamic semantics of this function are as follows:

For each item in $actual argument that is of type xs:untypedAtomic, that item is cast to the type of the $expected argument, and the resulting sequence is returned.

Static Type Analysis

The following static typing rules correspond to the dynamic semantics rules given above.

statEnv |-  Type₂ <: xs:anyAtomicType

Type₃ = convert_untypedAtomic(prime(Type₁), Type₂)

statEnv |-  (FS-URI,"convert-simple-operand")( Type₁, Type₂) : Type₃ · quantifier(Type₁)

7.1.3 The fs:distinct-doc-order function

fs:distinct-doc-order($nodes as node *) as node *

The fs:distinct-doc-order function sorts its input sequence of nodes by document order and removes duplicates.

Static Type Analysis

The fs:distinct-doc-order function expects a sequence of nodes as input. The resulting type is computed using prime and quantifier, which are defined in [8.4 Judgments for FLWOR and other expressions on sequences].

statEnv  |-  Type <: node*

statEnv |-  (FS-URI,"distinct-doc-order") ( Type ) : prime(Type) · quantifier(Type)

7.1.4 The fs:distinct-doc-order-or-atomic-sequence function

fs:distinct-doc-order-or-atomic-sequence( $item as item()*) as item()*

The fs:distinct-doc-order-or-atomic-sequence function operates on either an homogeneous sequence of nodes or an homogeneous sequence of atomic values. If the input is a sequence of nodes, is sorts those nodes by document order and removes duplicates, using the fs:distinct-doc-order function. If it is a sequence of atomic values, it returns it unchanged.

Static Type Analysis

The fs:distinct-doc-order function expects either a sequence of nodes as input or a sequence of atomic values. The resulting type is computed using prime and quantifier, which are defined in [8.4 Judgments for FLWOR and other expressions on sequences].

statEnv  |-  Type <: [node()]sequencetype*

statEnv |-  (FS-URI," distinct-doc-order-or-atomic-sequence") ( Type ) : prime(Type) · quantifier(Type)

statEnv  |-  Type <: xs:anyAtomicType*

statEnv |-  (FS-URI," distinct-doc-order-or-atomic-sequence") ( Type ) : Type

7.1.5 The fs:item-sequence-to-node-sequence function

fs:item-sequence-to-node-sequence($items as item()*) as node()*

The fs:item-sequence-to-node-sequence function converts a sequence of item values to nodes by applying the normative rules numbered 1, 2, 3 after the sentence "Processing of the computed element constructor proceeds as follows:" in Section 3.7.3.1 Computed Element ConstructorsXQ.

Static Type Analysis

statEnv |-  Type <: attribute*, (element|document|text|processing-instruction|comment|xs:string| xs:float| ...|xs:NOTATION)*

statEnv |-  (FS-URI,"item-sequence-to-node-sequence") (Type) : attribute*, (element|text|processing-instruction|comment)*

7.1.6 The fs:item-sequence-to-node-sequence-doc function

fs:item-sequence-to-node-sequence-doc( $items as item()*) as node()*

The fs:item-sequence-to-node-sequence-doc function converts a sequence of item values to nodes by applying the normative rules numbered 1, 2, 3 after the sentence "Processing of the document node constructor then proceeds as follows:" in Section 3.7.3.3 Document Node ConstructorsXQ.

Static Type Analysis

statEnv |-  Type <: (element|document|text|processing-instruction|comment|xs:string| xs:float| ...|xs:NOTATION)*

statEnv |-  (FS-URI,"item-sequence-to-node-sequence-doc") (Type) : (element|text|processing-instruction|comment)*

7.1.7 The fs:item-sequence-to-untypedAtomic function

Introduction

fs:item-sequence-to-untypedAtomic($items as item()*) as xs:untypedAtomic

The fs:item-sequence-to-untypedAtomic function converts a sequence of item values to a string of type xs:untypedAtomic by applying the normative rules in Section 3.7.3.2 Computed Attribute ConstructorsXQ for processing the content expression.

Dynamic Evaluation

If the input of the fs:item-sequence-to-untypedAtomic function is an empty sequence, it returns a zero-length string. Otherwise, each atomic value in the input sequence is cast into a string. 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.

Static Type Analysis

There are no special static typing rules for this function. Static type analysis for this function should be performed as for a built-in function declared with the given signature.

7.1.8 The fs:item-sequence-to-untypedAtomic-PI function

Introduction

fs:item-sequence-to-untypedAtomic-PI($items as item()*) as xs:untypedAtomic

The fs:item-sequence-to-untypedAtomic-PI function converts a sequence of item values to a string of type xs:untypedAtomic by applying the normative rules in Section 3.7.3.5 Computed Processing Instruction ConstructorsXQ for processing the content expression.

Dynamic Evaluation

If the input is an empty sequence, the fs:item-sequence-to-untypedAtomic-PI function returns a zero-length string. Otherwise, each atomic value in the input sequence is cast into a string. If any of the resulting strings contains the string "?>", a dynamic error is raised. 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. Leading whitespace is removed from the resulting string.

Static Type Analysis

There are no special static typing rules for this function. Static type analysis for this function should be performed as for a built-in function declared with the given signature.

7.1.9 The fs:item-sequence-to-untypedAtomic-text function

Introduction

fs:item-sequence-to-untypedAtomic-text( $items as item()*) as xs:untypedAtomic?

The fs:item-sequence-to-untypedAtomic-text function converts a sequence of item values to a string of type xs:untypedAtomic, or empty, by applying the rules in Section 3.7.3.4 Text Node ConstructorsXQ for processing the content expression.

Dynamic Evaluation

If the input is the empty sequence, the fs:item-sequence-to-untypedAtomic-text function returns the empty sequence. Otherwise, each atomic value in the input sequence is cast into a string. 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.

Static Type Analysis

There are no special static typing rules for this function. Static type analysis for this function should be performed as for a built-in function declared with the given signature.

7.1.10 The fs:item-sequence-to-untypedAtomic-comment function

Introduction

fs:item-sequence-to-untypedAtomic-comment( $items as item()*) as xs:untypedAtomic

The fs:item-sequence-to-untypedAtomic-comment function converts a sequence of item values to a string of type xs:untypedAtomic by applying the normative rules in Section 3.7.3.6 Computed Comment ConstructorsXQ for processing the content expression.

Dynamic Evaluation

If the input is the empty sequence, the fs:item-sequence-to-untypedAtomic-comment function returns a zero-length string. Otherwise, each atomic value in the input sequence is cast into a string. 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. It is a dynamic error if the result of the content expression of a computed comment constructor contains two adjacent hyphens or ends with a hyphen.

Static Type Analysis

There are no special static typing rules for this function. Static type analysis for this function should be performed as for a built-in function declared with the given signature.

7.1.11 The fs:apply-ordering-mode function

fs:apply-ordering-mode($items as item()*) as item()*

Dynamic Evaluation

If the statEnv.orderingMode is set to ordered, the fs:apply-ordering-mode function is the identity function, returning its input sequence in its original order.

statEnv.orderingMode = ordered      dynEnv  |-  Expr => Value

dynEnv  |-  fs:apply-ordering-mode( Expr) => Value

If the statEnv.orderingMode is set to unordered, the fs:apply-ordering-mode is equivalent to the fn:unordered function, returning the items from its input sequence in arbitrary order.

statEnv.orderingMode = unordered      dynEnv  |-  fn:unordered(Expr) => Value

dynEnv  |-  fs:apply-ordering-mode( Expr) => Value

Static Type Analysis

If the ordering context is set to ordered, the static type of the input expression of the fs:apply-ordering-mode function is left unchanged.

statEnv.orderingMode = ordered

statEnv  |-  (FS-URI,"apply-ordering-mode")( Type) : Type

If the ordering context is set to unordered, the static type of the input expression of the fs:apply-ordering-mode function is computed using the prime and quantifier judgments, as for the fn:unordered function.

statEnv.orderingMode = unordered

statEnv  |-  (FS-URI,"apply-ordering-mode")( Type) : prime(Type) · quantifier(Type)

7.1.12 The fs:to function

fs:to($firstval as xs:integer?, $lastval as xs:integer?) as xs:integer*

The formal semantics function fs:to is a wrapper function for the op:to operator, taking the semantics of the range expression over empty sequences into account.

Dynamic Evaluation

If one of the input parameters for fs:to is the empty sequence, the function returns the empty sequence, otherwise it returns the result of calling the op:to operator. This semantics is equivalent to the following user-defined function.

declare function fs:to($firstval as xs:integer?, $lastval as xs:integer?) as xs:integer* {
  if (fn:empty($firstval) or fn:empty($lastval)
  then ()
  else op:to($firstval,$lastval)
};

Static Type Analysis

The static type of fs:to does not require any additional static typing rule, and is typed as a function call based on the above signature.

7.2 Standard functions with specific static typing rules

Introduction

This section gives special normalization and static typing rules for functions in [Functions and Operators] for which the standard normalization or static typing rules are not appropriate. All functions that are not mentioned behave as described in Section [4.1.5 Function Calls]. When given, the static typing rules in this section always give more precise type information than the generic rule based on the function's signature.

7.2.1 The fn:last context function

As explained in [3.1.2 Dynamic Context], the fn:last() context function is modeled using the Formal Semantics variable $fs:last. For that function the following static typing and dynamic evaluation rules apply.

Static Type Analysis

statEnv.varType((FS-URI,"last")) = Type

statEnv |-  (FN-URI,"last")() : Type

Dynamic Evaluation

dynEnv.varValue((FS-URI,"last")) = Value

dynEnv |-  function (FN-URI,"last")() with types on values yields Value

7.2.2 The fn:position context function

As explained in [3.1.2 Dynamic Context], the fn:position() context function is modeled using the Formal Semantics variable $fs:position. For that function the following static typing and dynamic evaluation rules apply.

Static Type Analysis

statEnv.varType((FS-URI,"position")) = Type

statEnv |-  (FN-URI,"position")() : Type

Dynamic Evaluation

dynEnv.varValue((FS-URI,"position")) = Value

dynEnv |-  function (FN-URI,"position")() with types on values yields Value

7.2.3 The fn:abs, fn:ceiling, fn:floor, fn:round, and fn:round-half-to-even functions

Static Type Analysis

The static typing rules for the fn:abs, fn:ceiling, fn:floor, fn:round, and fn:round-half-to-even functions promote their input type to the (least) base primitive numeric type from which the input type is derived. Note that the fact that the type should be the least is cannot expressed by the inference rule notation used here. Parameters of type xs:untypedAtomic are always promoted to xs:double. Instead of writing a separate judgment for each function, we write one rule for the functions whose name is either (FN-URI,"abs"), (FN-URI,"ceiling"), (FN-URI,"floor"), (FN-URI,"round"), or (FN-URI,"round-half-to-even") functions.

Type₁ in { xs:integer, xs:decimal, xs:float, xs:double }

statEnv |-  Type <: xs:anyAtomicType ?

Type₂ = convert_untypedAtomic(Type, xs:double)

statEnv |-  Type₂ can be promoted to Type₁

expanded-QName in { (FN-URI,"ceiling"), (FN-URI,"floor"), (FN-URI,"round"), (FN-URI,"round-half-to-even") }

statEnv |-  expanded-QName (Type) : Type₁ · quantifier(Type)

7.2.4 The fn:boolean function

Static Type Analysis

The fn:boolean function as described in the [Functions and Operators] document takes an empty sequence, a sequence of one or more nodes, or a singleton value of type xs:boolean, xs:string, xs:untypedAtomic or some numeric type. All other values are illegal.

statEnv |-  Type <: (empty | NodeType+ | xs:boolean | xs:string | xs:untypedAtomic | fs:numeric | xs:anyURI)

statEnv  |-  (FN-URI,"boolean")(Type) : xs:boolean

7.2.5 The fn:collection and fn:doc functions

Introduction

The static typing rules for fn:collection and fn:doc depend on the syntactic form of their input expression. As a result, the corresponding static typing rules must be written directly over the input expression, unlike the other functions in this section.

Static Type Analysis

The fn:collection function as described in the [Functions and Operators] document, takes a string-valued expression, which denotes a URI, and returns a value.

If the fn:collection function has no parameter, the result type is given by the implementation for the default sequence if it exists.

statEnv |-  QName of func expands to (FN-URI,"collection")

statEnv  |-  Implementation-defined default sequence has type Type

statEnv  |-  QName() : Type

If the argument to fn:collection is a URILiteral expression which is defined in statEnv.collectionType, then the result type is the type corresponding to the URILiteral in statEnv.collectionType.

statEnv |-  QName of func expands to (FN-URI,"collection")

statEnv.collectionType(URILiteral) = Type

statEnv  |-  QName(URILiteral) : Type

Otherwise, if the argument is a URI literal but is not defined in statEnv.collectionType, or if it is not a URI literal, then we don't know anything about the URI and the static type is a collection of nodes.

statEnv |-  QName of func expands to (FN-URI,"collection")

statEnv.collectionType(URILiteral) undefined

statEnv  |-  QName(URILiteral) : (element | attribute | processing-instruction | text | comment | document ) *

statEnv |-  QName of func expands to (FN-URI,"collection")

Expr is not a URILiteral

statEnv  |-  QName(Expr) : (element | attribute | processing-instruction | text | comment | document ) *

The fn:doc function has similar static typing rules, but, in addition, the static type must be a document node.

statEnv |-  QName of func expands to (FN-URI,"doc")

statEnv.docType(URILiteral) = Type

statEnv  |-  Type <: document

statEnv  |-  QName(URILiteral) : Type

Otherwise, if the argument is a URI literal not defined in the domain of statEnv.docType or if it is not a URI literal, then we don't know anything about the URI, and the static type is document.

statEnv |-  QName of func expands to (FN-URI,"doc")

statEnv.docType(URILiteral) undefined

statEnv  |-  QName(URILiteral) : document?

statEnv |-  QName of func expands to (FN-URI,"doc")

Expr is not a URILiteral

statEnv  |-  QName(Expr) : document?

7.2.6 The fn:data function

Introduction

The fn:data function converts a sequence of items to a sequence of atomic values.

Notation

Inferring the type for the fn:data function is done by applying the data on auxiliary judgment, using the same approach as for the XPath steps.

statEnv |-  data on Type₁ : Type₂

Static Type Analysis

The general rule for fn:data is to apply the filter data on to the prime type of its argument type, then apply the quantifier to the result:

statEnv |-  data on prime(Type) : Type₁

statEnv |-  (FN-URI,"data")(Type) : Type₁ · quantifier(Type)

When applied to none, data on yields none.

statEnv |-  data on none : none

When applied to empty, data on yields empty.

statEnv |-  data on empty : empty

When applied to the union of two types, data on is applied to each of the two types. The resulting type is computed using prime and quantifier, which are defined in [8.4 Judgments for FLWOR and other expressions on sequences]. This rule is necessary because data on may return a sequence of atomic types.

statEnv |-  data on Type₁ : Type₁'

statEnv |-  data on Type₂ : Type₂'

statEnv |-  data on (Type₁|Type₂) : prime(Type₁'|Type₂') · quantifier(Type₁'|Type₂')

When applied to an atomic type, data on simply returns the atomic type:

statEnv  |-  Type <: xs:anyAtomicType

statEnv |-  data on Type : Type

When applied to comment or processing instruction node types, data on returns xs:string

statEnv  |-  Type <: comment | processing-instruction

statEnv |-  data on Type : xs:string

When applied to text or document node types, data on returns xs:untypedAtomic

statEnv  |-  Type <: text | document

statEnv |-  data on Type : xs:untypedAtomic

When applied to element node types with type annotationXQ xs:untyped, the data on filter returns xs:untypedAtomic.

statEnv |-  ElementType type lookup of type xs:untyped

statEnv |-  data on ElementType : xs:untypedAtomic

When applied to an attribute node type, the data on filter returns the attribute's simple type.

statEnv |-  AttributeType type lookup of type TypeName

statEnv |-  of type TypeName expands to Type

statEnv |-  data on AttributeType : Type

When applied to an element type whose type annotationXQ denotes a simple type or a complex type of simple content, data on returns the element's simple type.

statEnv |-  ElementType type lookup TypeReference

statEnv |-  TypeReference expands to Type

statEnv  |-  Type <: (attribute*, Type₁)      statEnv  |-  Type₁ <: xs:anyAtomicType*

statEnv |-  data on ElementType : Type₁

When applied to an element type whose type annotationXQ denotes a complex type of mixed content, the data on filter returns xs:untypedAtomic.

statEnv |-  ElementType type lookup of type TypeName

statEnv |-  TypeName of elem/type expands to expanded-QName      statEnv.typeDefn(expanded-QName) = define type TypeName Derivation mixed { Type₁ }

statEnv |-  data on ElementType : xs:untypedAtomic

The data on filter is not defined on any element type whose type annotationXQ denotes a complex type of complex content and therefore applying data on to such a node raises a static error.

Example

Consider the following variable and its corresponding static type.

    $x : (element price { attribute currency { xs:string }, xs:decimal }
         | element price_code { xs:integer })

Applying the fn:data function on that variable results in the following type.

    fn:data($x) : (xs:decimal | xs:integer)

Because the input type is a choice, applying the data on filter results in a choice of simple types for the output of the fn:data function.

7.2.7 The fn:distinct-values function

Static Type Analysis

The fn:distinct-values function expects a sequence of atomic values as input and returns a sequence of prime types, which are defined in [8.4 Judgments for FLWOR and other expressions on sequences].

statEnv  |-  Type <: xs:anyAtomicType*

statEnv  |-  (FN-URI,"distinct-values")(Type) : prime(Type) · quantifier(Type)

7.2.8 The fn:unordered function

Static Type Analysis

The static semantics for fn:unordered is computed using prime and quantifier, which are defined in [8.4 Judgments for FLWOR and other expressions on sequences]. The type of the argument is determined, and then prime(.) and quantifier(.) are applied to that type.

statEnv  |-  (FN-URI,"unordered")(Type₁) : prime(Type₁) · quantifier(Type₁)

7.2.9 The fn:error function

Static Type Analysis

The fn:error function always has the none type.

statEnv  |-  (FN-URI,"error")() : none

statEnv  |-  Type <: xs:QName

statEnv  |-  (FN-URI,"error")(Type) : none

statEnv  |-  Type₁ <: xs:QName?     statEnv  |-  Type₂ <: xs:string

statEnv  |-  (FN-URI,"error")(Type₁,Type₂) : none

statEnv  |-  Type₁ <: xs:QName?     statEnv  |-  Type₂ <: xs:string

statEnv  |-  (FN-URI,"error")(Type₁,Type₂,Type₃) : none

7.2.10 The fn:min, fn:max, fn:avg, and fn:sum functions

Introduction

The semantics of aggregate functions convert any item of type xs:untypedAtomic in the input sequence to xs:double, then attempt to promote all values in the input sequence to values that are comparable. The static typing rules reflect the dynamic evaluation rules.

The fn:sum function has two forms. The first form takes two arguments: The first argument is the input sequence and the second argument is the value that should be returned if the input sequence is empty. In case there is no second argument, the value returned for an empty sequence is the xs:integer value 0. The following static typing rule applies in the case there is no second argument.

Static Type Analysis

statEnv |-  (FN-URI,"sum")(Expr,0) : Type

statEnv |-  (FN-URI,"sum")(Expr) : Type

Notation

The type function convert_untypedAtomic takes a prime type and converts all occurrences of the type xs:untypedAtomic to a target type. It is defined recursively as follows.

| convert_untypedAtomic(xs:untypedAtomic, Type) |   =   | Type
if not(FormalItemType = xs:untypedAtomic) | convert_untypedAtomic(FormalItemType, Type) |   =   | FormalItemType
| convert_untypedAtomic(empty, Type) |   =   | empty
| convert_untypedAtomic(none, Type) |   =   | none
| convert_untypedAtomic(Type₁ | Type₂, Type) |   =   | convert_untypedAtomic(Type₁, Type) | convert_untypedAtomic(Type₂, Type)

Notation

The function aggregate_quantifier converts the input type quantifier zero-or-more or zero-or-one to the result type quantifier zero-or-one, and converts the input type quantifier one or one-or-more, to the result type quantifier one.

aggregate_quantifier(?) |   =   | ?
aggregate_quantifier(*) |   =   | ?
aggregate_quantifier(1) |   =   | 1
aggregate_quantifier(+) |   =   | 1

Static Type Analysis

Now we can define the static typing rules for the aggregate functions. First, the input type is converted to a prime type. Second, the type function convert_untypedAtomic is applied to the prime type, yielding a new prime type, in which occurrences of xs:untypedAtomic are converted to xs:double. Third, the judgment can be promoted to is applied to the new prime type and target type. The result type is combined with the aggregate quantifier of the input type.

For a given aggregate function, instead of writing a separate judgment for each target type, we write one rule using a target type Type₀.

For fn:min and fn:max, the target type Type₀ is either xs:string, xs:integer, xs:decimal, xs:float, xs:double, xs:date, xs:time, xs:dateTime, xs:yearMonthDuration, or xs:dayTimeDuration .

Type₁ = prime(Type)

Type₂ = convert_untypedAtomic(Type₁, xs:double)

Type₂ = empty

statEnv |-  (FN-URI,"min")(Type) : empty

Type₁ = prime(Type)

Type₂ = convert_untypedAtomic(Type₁, xs:double)

FormalItemType 1, ...,FormalItemType n = Type₂

statEnv |-  FormalItemType 1 can be promoted to Type₀

...

statEnv |-  FormalItemType n can be promoted to Type₀

Type₀ in { xs:string, xs:integer, xs:decimal, xs:float, xs:double, xs:date, xs:time, xs:dateTime, xs:yearMonthDuration, xs:dayTimeDuration }

statEnv |-  (FN-URI,"min")(Type) : Type₀ · aggregate_quantifier(quantifier(Type))

Type₁ = prime(Type)

Type₂ = convert_untypedAtomic(Type₁, xs:double)

Type₂ = empty

statEnv |-  (FN-URI,"max")(Type) : empty

Type₁ = prime(Type)

Type₂ = convert_untypedAtomic(Type₁, xs:double)

Type₂ = FormalItemType 1, ...,FormalItemType n

statEnv |-  FormalItemType 1 can be promoted to Type₀

...

statEnv |-  FormalItemType n can be promoted to Type₀

Type₀ in { xs:string, xs:integer, xs:decimal, xs:float, xs:double, xs:date, xs:time, xs:dateTime, xs:yearMonthDuration, xs:dayTimeDuration }

statEnv |-  (FN-URI,"max")(Type) : Type₀ · aggregate_quantifier(quantifier(Type))

For fn:avg, the target type Type₀ is either xs:decimal, xs:float, xs:double, xs:yearMonthDuration, or xs:dayTimeDuration .

Type₁ = prime(Type)

Type₂ = convert_untypedAtomic(Type₁, xs:double)

Type₂ = empty

statEnv |-  (FN-URI,"avg")(Type) : empty

Type₁ = prime(Type)

Type₂ = convert_untypedAtomic(Type₁, xs:double)

FormalItemType 1, ...,FormalItemType n = Type₂

statEnv |-  FormalItemType 1 can be promoted to Type₀

...

statEnv |-  FormalItemType n can be promoted to Type₀

Type₀ in { xs:decimal, xs:float, xs:double, xs:yearMonthDuration, xs:dayTimeDuration }

statEnv |-  (FN-URI,"avg")(Type) : Type₀ · aggregate_quantifier(quantifier(Type))

For fn:sum, the target type Type₀ is either xs:integer, xs:decimal, xs:float, xs:double, xs:yearMonthDuration, or xs:dayTimeDuration . The second argument in fn:sum is the value that should be returned if the input sequence is empty. The result type is the union of the target type and the type of the second argument. Note that the rule checks that the type for the zero value is consistent with the type of the input sequence.

Type₁ = prime(Type)

Type₂ = convert_untypedAtomic(Type₁, xs:double)

Type₂ = empty

statEnv |-  (FN-URI,"sum")(Type) : xs:integer

statEnv |-  Type₂ <: xs:anyAtomicType ?

Type₃ = prime(Type₁)

Type₄ = convert_untypedAtomic(Type₃, xs:double)

FormalItemType 1, ...,FormalItemType n = Type₄

statEnv |-  FormalItemType 1 can be promoted to Type₀

...

statEnv |-  FormalItemType n can be promoted to Type₀

statEnv |-  Type₂ <: Type₀

Type₀ in { xs:integer, xs:decimal, xs:float, xs:double, xs:yearMonthDuration }

statEnv |-  (FN-URI,"sum")(Type₁,Type₂) : Type₀ · aggregate_quantifier(quantifier(Type₁))

7.2.11 The fn:remove function

Static Type Analysis

The static type for the fn:remove function is computed using prime and quantifier, which are defined in [8.4 Judgments for FLWOR and other expressions on sequences]. Since one item may be removed from the sequence, the resulting type is made optional.

statEnv |-  Type₁ <: xs:integer

statEnv |-  (FN-URI,"remove")(Type, Type₁) : prime(Type) · quantifier(Type) · ?

7.2.12 The fn:reverse function

Static Type Analysis

The static type for the fn:reverse function is computed using prime and quantifier, which are defined in [8.4 Judgments for FLWOR and other expressions on sequences].

statEnv |-  (FN-URI,"reverse")(Type) : prime(Type) · quantifier(Type)

7.2.13 The fn:subsequence function

Introduction

The fn:subsequence function has special static typing rules when its second argument is the numeric literal value 1 or the built-in variable $fs:last. These rules provide better typing for path expressions such as Expr[1] and Expr[fn:last()].

The static typing rules for fn:subsequence depends on the syntactic form of their input expression. As a result, the corresponding static typing rules must be written directly over the input expression, unlike the other functions in this section.

Static Type Analysis

If the type of the input expression has exactly one or one-or-more items, then the type inferred for fn:subsequence is the prime type of the input type.

statEnv |-  QName of func expands to (FN-URI,"subsequence")

statEnv |-  Expr : Type      quantifier(Type) in { 1, + }

statEnv  |-  QName(Expr, 1, 1) : prime(Type)

If the type of the input expression has zero or more items, fn:subsequence is applied on a numeric literal, $fs:position, or $fs:last, then the static type is zero-or-one of the prime type of the input type. Those static typing rules are intended to support more precise typing for the cases where fn:subsequence is the result of normalizing an XPath predicate of the form Expr[NumericLiteral] of Expr[last()], see [4.2.1 Steps].

statEnv |-  QName of func expands to (FN-URI,"subsequence")

statEnv |-  Expr : Type      quantifier(Type) in { *, + }

statEnv  |-  QName(Expr, NumericLiteral, 1) : prime(Type) ?

The same rule applies when the last item in the input sequence is selected.

statEnv |-  QName of func expands to (FN-URI,"subsequence")

statEnv |-  Expr : Type      quantifier(Type) in { *, + }

statEnv  |-  QName(Expr, $fs:last, 1) : prime(Type) ?

The same rule applies when an item is selected based on its position in the input sequence.

statEnv |-  QName of func expands to (FN-URI,"subsequence")

statEnv |-  Expr : Type      quantifier(Type) in { *, + }

statEnv  |-  QName(Expr, $fs:position, 1) : prime(Type) ?

The last rule applies to all other applications of the fn:subsequence function.

statEnv |-  QName of func expands to (FN-URI,"subsequence")

statEnv |-  Expr : Type

statEnv |-  Expr₁ : xs:double      statEnv |-  Expr₂ : xs:double

statEnv |-  QName(Expr, Expr₁, Expr₂) : prime(Type) · quantifier(Type) · ?

7.2.14 The op:union, op:intersect, and op:except operators

Static Type Analysis

The static semantics for op:union is computed using prime and quantifier, which are defined in [8.4 Judgments for FLWOR and other expressions on sequences]. The type of each argument is determined, and then prime(.) and quantifier(.) are applied to the sequence type (Type₁, Type₂).

statEnv  |-  (OP-URI,"union")(Type₁, Type₂) : prime(Type₁ , Type₂) · quantifier(Type₁ , Type₂)

The static semantics of op:intersect is analogous to that for op:union. Because an intersection may be empty, the result type is optional.

statEnv  |-  (OP-URI,"intersect")(Type₁, Type₂) : prime(Type₁, Type₂) · quantifier(Type₁,Type₂) · ?

The static semantics of op:except follows. The type of the second argument is ignored as it does not contribute to the result type. As with op:intersect, the result of op:except may be the empty sequence.

statEnv  |-  (OP-URI,"except")(Type₁, Type₂) : prime(Type₁) · quantifier(Type₁) · ?

7.2.15 The fn:insert-before function

Static Type Analysis

The static type for the fn:insert-before function is computed using prime and quantifier, which are defined in [8.4 Judgments for FLWOR and other expressions on sequences].

statEnv |-  Type₂ <: xs:integer

Type₄ = (Type₁,Type₃)

statEnv |-  (FN-URI,"insert-before")(Type₁,Type₂,Type₃) : prime(Type₄) · quantifier(Type₄)

7.2.16 The fn:zero-or-one, fn:one-or-more, and fn:exactly-one functions

The functions fn:zero-or-one, fn:one-or-more, and fn:exactly-one check that the cardinality of a sequence is in the expected range. They are useful to override the static type inferred for a given query.

For example, in the following query, the user may know that all ISBN numbers are unique and therefore that the function always returns at most one book element. However, the static typing feature cannot infer a precise enough type and will raise a type error during static type analysis.

  declare function book_with_isbn($isbn as xs:string) as schema-element(book)? {
    //book[@isbn=$isbn]
  }

In that query, the fn:zero-or-one function can be used to tell the type system that the cardinality is known to be zero or one.

  declare function book_with_isbn($isbn as xs:string) as schema-element(book)? {
    fn:zero-or-one(//book[@isbn=$isbn])
  }

Static Type Analysis

The static typing rules for those functions always infer a type with the cardinality indicated by that function.

statEnv  |-  (FN-URI,"zero-or-one")(Type) : prime(Type)?

statEnv  |-  (FN-URI,"one-or-more")(Type) : prime(Type)+

statEnv  |-  (FN-URI,"exactly-one")(Type) : prime(Type)

8 Auxiliary Judgments

This section defines auxiliary judgments used in defining the formal semantics. Many auxiliary judgments are used in both static typing and dynamic evaluation rules. Those auxiliary judgments that are used in only the static or dynamic semantics are labeled as such.

8.1 Judgments for accessing types

Introduction

This section defines several auxiliary judgments to access components of the [XPath/XQuery] type system. The first two judgments (derives from and substitutes for) are used to access the type and element name hierarchies in an XML Schema. The other judgments (name lookup, type lookup, extended by, adjusts to and expands to) are used to lookup the meaning of element or attribute types from the schema. These judgments are used in many expressions, notably in the specification of type matching (See [8.3 Judgments for type matching]), validation (See [F.1 Judgments for the validate expression]), and the static semantics of step expressions (See [8.2 Judgments for step expressions and filtering]).

8.1.1 Derives from

Notation

The judgment

statEnv |-  TypeName₁ derives from TypeName₂

holds when TypeName₁ derives from TypeName₂. This judgment formalizes the definition of the derives-from function in Section 2.5.4 SequenceType MatchingXQ.

Example

For example, assuming the extended XML Schema given in section [2.4.5 Example of a complete Schema], then the following judgments hold.

  USAddress            derives from  xs:anyType
  NYCAddress           derives from  USAddress
  NYCAddress           derives from  xs:anyType
  xsd:positiveInteger  derives from  xsd:integer
  xsd:integer          derives from  xs:anySimpleType
  fs:anon3             derives from  xsd:positiveInteger
  fs:anon3             derives from  xsd:integer
  fs:anon3             derives from  xs:anySimpleType
  fs:anon3             derives from  xs:anyType

Note

Derivation is a partial order. It is reflexive and transitive by the definition below.

Semantics

This judgment is specified by the following rules.

Every type name derives from itself.

statEnv |-  TypeName derives from TypeName

Every type name derives from the type it is declared to derive from by extension or restriction.

statEnv |-  TypeName of elem/type expands to expanded-QName

statEnv.typeDefn(expanded-QName) = define type TypeName extends BaseTypeName OptMixed { Type }

statEnv |-  TypeName derives from BaseTypeName

statEnv |-  TypeName of elem/type expands to expanded-QName

statEnv.typeDefn(expanded-QName) = define type TypeName restricts BaseTypeName OptMixed { Type }

statEnv |-  TypeName derives from BaseTypeName

The above rules all require that the type names be defined in the static context, but [XPath/XQuery] permits references to "unknown" type names, i.e., type names that are not defined in the static context. An unknown type name might be encountered, if a module in which the given type name occurs does not import the schema in which the given type name is defined. In this case, an implementation is allowed (but is not required) to provide an implementation-dependent mechanism for determining whether the unknown type name is the same as or derived by restriction from the expected type name. The following rule formalizes this implementation dependent mechanism.

"The implementation is able to determine that TypeName₁ is derived by restriction from TypeName₂."

statEnv |-  TypeName₁ derives from TypeName₂

The derivation relation is transitive.

statEnv |-  TypeName₁ derives from TypeName₂      statEnv |-  TypeName₂ derives from TypeName₃

statEnv |-  TypeName₁ derives from TypeName₃

8.1.2 Substitutes for

The substitutes judgment is used to know whether an element name is in the substitution group of another element name.

Notation

The judgment

statEnv |-  ElementName₁ substitutes for ElementName₂

holds when ElementName₁ substitutes for ElementName₂.

Example

For example, assuming the extended XML Schema given in section [2.4.5 Example of a complete Schema], then the following judgments hold.

  usaddress  substitutes for  address
  nyaddress  substitutes for  usaddress
  nyaddress  substitutes for  address

Note

Substitution is a partial order. It is reflexive and transitive by the definition below. It is asymmetric because no cycles are allowed in substitution groups.

Semantics

The substitutes judgment for element names is specified by the following rules.

Every element name substitutes for itself.

statEnv |-  ElementName substitutes for ElementName

Every element name substitutes for the element it is declared to substitute for.

statEnv |-  ElementName of elem/type expands to expanded-QName

statEnv.elemDecl(expanded-QName) = define element ElementName substitutes for BaseElementName OptNillable TypeReference

statEnv |-  ElementName substitutes for BaseElementName

Substitution is transitive.

statEnv |-  ElementName₁ substitutes for ElementName₂      statEnv |-  ElementName₁ substitutes for ElementName₃

statEnv |-  ElementName₁ substitutes for ElementName₃

8.1.3 Element and attribute name lookup (Dynamic)

The name lookup judgment is used in the definition of the matches judgment, which takes a value and a type and determines whether the value matches, or is an instance of, the given type. Both name lookup and matches are used in the dynamic semantics.

The name lookup judgment takes an element(attribute) name (derived from a node value) and an element(attribute) type and if the element(attribute) name matches the corresponding name in the element(attribute) type, the judgment yields the type's corresponding type reference and for elements, its nillable property.

Notation

The judgment

statEnv |-  ElementName name lookup ElementType yields OptNillable TypeReference

holds when the given element name matches the given element type and requires that the element be nillable as indicated and have the given type reference.

Example

For example, assuming the extended XML Schema given in section [2.4.5 Example of a complete Schema], then the following judgments hold.

  comment    name lookup element comment                          yields of type xsd:string
  size       name lookup element size nillable of type xs:integer yields nillable of type xsd:string
  apt        name lookup element apt                              yields of type fs:anon3
  nycaddress name lookup element address                          yields of type NYCAddress

Note that when the element name is in a substitution group, the name lookup returns the type name corresponding to the original element name (here the type NYCAddress for the element nycaddress, instead of Address for the element address).

Semantics

This judgment is specified by the following rules.

If the element type is a reference to a global element, then name lookup yields the type reference in the element declaration for the given element name. The given element name must be in the substitution group of the global element.

statEnv |-  ElementName₁ substitutes for ElementName₂

statEnv |-  ElementName₁ of elem/type expands to expanded-QName₁

statEnv.elemDecl(expanded-QName₁) = define element ElementName₁ OptSubstitution OptNillable TypeReference

statEnv |-  ElementName₁ name lookup element ElementName₂ yields OptNillable TypeReference

If the given element name matches the element name in the element type, and the element type contains a type reference, then name lookup yields that type reference.

statEnv |-  ElementName name lookup element ElementName OptNillable TypeReference yields OptNillable TypeReference

If the element type has no element name but contains a type reference, then name lookup yields the type reference.

statEnv |-  ElementName name lookup element TypeReference yields TypeReference

If the element type has no element name and no type reference, then name lookup yields xs:anyType.

statEnv |-  ElementName name lookup element yields of type xs:anyType

Notation

The judgment

statEnv |-  AttributeName name lookup AttributeType yields TypeReference

holds when matching an attribute with the given attribute name against the given attribute type matches the type reference.

Example

For example, assuming the extended XML Schema given in section [2.4.5 Example of a complete Schema], then the following judgments hold.

  orderDate  name lookup  attribute orderDate of type xsd:date  yields  of type xsd:date?
  orderDate  name lookup  attribute of type xsd:date            yields  of type xsd:date?

Semantics

This judgment is specified by the following rules.

If the attribute type is a reference to a global attribute, then name lookup yields the type reference in the attribute declaration for the given attribute name.

statEnv |-  AttributeName of attr expands to expanded-QName

statEnv.attrDecl(expanded-QName) = define attribute AttributeName TypeReference

statEnv |-  AttributeName name lookup attribute AttributeName yields TypeReference

If the given attribute name matches the attribute name in the attribute type, and the attribute type contains a type reference, then name lookup yields that type reference.

statEnv |-  AttributeName name lookup attribute AttributeName TypeReference yields TypeReference

If the attribute type has no attribute name but contains a type reference, then name lookup yields the type reference.

statEnv |-  AttributeName name lookup attribute TypeReference yields TypeReference

If the attribute type has no attribute name and no type reference, then name lookup yields xs:anySimpleType.

statEnv |-  AttributeName name lookup attribute yields of type xs:anySimpleType

8.1.4 Element and attribute type lookup (Static)

The type lookup judgments are used to obtain the appropriate type reference for an attribute or element.

Notation

The judgment

statEnv |-  ElementType type lookup OptNillable TypeReference

holds when the element type is optionally nillable and has the given type reference.

Semantics

The element type lookup judgments are specified by the following rules.

A reference to a global element yields the type reference in the global element declaration with the given element name.

statEnv |-  ElementName of elem/type expands to expanded-QName

statEnv.elemDecl(expanded-QName) = define element ElementName OptSubstitution OptNillable TypeReference

statEnv |-  element ElementName type lookup OptNillable TypeReference

In the case of a local element type, type lookup yields the corresponding type reference.

statEnv |-  element ElementName OptNillable TypeReference type lookup OptNillable TypeReference

If the element type has no element name but contains a type reference, then type lookup yields that type reference.

statEnv |-  element OptNillable TypeReference type lookup TypeReference

If the element type has no element name and no type reference, then lookup yields xs:anyType.

statEnv |-  element type lookup of type xs:anyType

Notation

The judgment

statEnv |-  AttributeType type lookup TypeReference

holds when the attribute type has the given type reference.

Semantics

This judgment is specified by the following rules.

A reference to a global attribute yields the type reference in the global attribute declaration with the given attribute name.

statEnv |-  AttributeName of attr expands to expanded-QName

statEnv.attrDecl(expanded-QName) = define attribute AttributeName TypeReference

statEnv |-  attribute AttributeName type lookup TypeReference

If the attribute name is not defined, i.e., it is not declared in the in-scope schema definitions, then the attribute's default type is xs:untypedAtomic.

statEnv |-  AttributeName of attr expands to expanded-QName

statEnv.attrDecl(expanded-QName) undefined

statEnv |-  attribute AttributeName type lookup of type xs:untypedAtomic

In the case of a local attribute type, type lookup yields the corresponding type reference.

statEnv |-  attribute AttributeName TypeReference type lookup TypeReference

If the attribute type has no attribute name but contains a type reference, then type lookup yields the type reference.

statEnv |-  attribute TypeReference type lookup TypeReference

If the attribute type has no attribute name and no type reference, then type lookup yields xs:anySimpleType.

statEnv |-  attribute type lookup of type xs:anySimpleType

8.1.5 Extension

Notation

The judgment

statEnv |-  Type₁ extended by Type₂ is Type

holds when the result of extending Type₁ by Type₂ is Type. This judgment is used in the definition of type expansion [8.1.9 Type expansion], which expands a type to include the union of all types derived from the given type,

Semantics

This judgment is specified by the following rules.

statEnv |-  Type₁ = AttributeModel 1 , ElementModel₁      statEnv |-  Type₂ = AttributeModel 2 , ElementModel₂

statEnv |-  Type₁ extended by Type₂ is (AttributeModel 1 & AttributeModel 2) , ElementModel₁ , ElementModel₂

8.1.6 Mixed content

Notation

The judgment

statEnv |-  Type₁ mixes to Type₂

holds when the result of creating a mixed content from Type₁ is Type₂.

Semantics

This judgment is specified by the following rule, which interleaves the element content with a sequence of text nodes and adds a union of xs:anyAtomicType values. The xs:anyAtomicType sequence is required because it is possible to derive an element containing only atomic values from an element that is mixed.

statEnv |-  Type = AttributeModel , ElementModel

statEnv |-  Type mixes to AttributeModel , ( ElementModel & text* | xs:anyAtomicType *)

8.1.7 Type adjustment

In the [XPath/XQuery] type system, a complex-type declaration does not include the implicit attributes and nodes that may be included in the type. Type adjustment takes a complex type and adjusts it to include implicit attributes and nodes. In particular, type adjustment:

adds the four (optional) built-in attributes xsi:type, xsi:nil, xsi:schemaLocation, or xsi:noNamespaceSchemaLocation,

interleaves the type with a sequence of comments and processing-instructions, and

if the complex type is mixed, interleaves the type with a sequence of text nodes and xs:anyAtomicType.

Notation

The judgment

statEnv |-  OptMixed Type₁ adjusts to Type₂

holds when the second type is the same as the first after the first has been adjusted as described above.

Semantics

This judgment is specified by the following rules.

If the type is flagged as mixed, then mix the type and extend it by the built-in attributes.

statEnv |-  Type₁ mixes to Type₂

statEnv |-  Type₂ extended by BuiltInAttributes is Type₃

statEnv |-  Type₄ = Type₃ & processing-instruction* & comment*

statEnv |-  mixed Type₁ adjusts to Type₄

Otherwise, just extend the type by the built-in attributes.

statEnv |-  Type₁ extended by BuiltInAttributes is Type₂

statEnv |-  Type₃ = Type₂ & processing-instruction* & comment*

statEnv |-  Type₁ adjusts to Type₃

8.1.8 Builtin attributes

Schema defines four built-in attributes that can appear on any element in the document without being explicitly declared in the schema. Those four attributes need to be added inside content models when doing matching. The four built-in attributes of Schema are declared as follows.

  define attribute xsi:type of type xs:QName
  define attribute xsi:nil of type xs:boolean
  define attribute xsi:schemaLocation of type fs:anon
  define type fs:anon1 { xs:anyURI* }
  define attribute xsi:noNamespaceSchemaLocation of type xs:anyURI

For convenience, a type that is an all group of the four built-in XML Schema attributes is defined.

  BuiltInAttributes =
      attribute xsi:type ?
    & attribute xsi:nil ?
    & attribute xsi:schemaLocation ?
    & attribute xsi:noNamespaceSchemaLocation ?

8.1.9 Type expansion

The expands to judgment is one of the most important static judgments. It is used in the static semantics of the child axis [8.2.2.1 Static semantics of axes], which is used in the definition of many other rules that extract element types from an arbitrary content type.

The judgment takes a type name and computes the union of all types derived from the given type. If the type is nillable, it also makes sure the content model allows the empty sequence. If the type is mixed, it also adjusts the type to include the mixed content model. The judgment depends on the extended with union interpretation of judgment to recursively compute all derived types.

Notation

The judgment

statEnv |-  TypeSpecifier expands to Type

holds when expanding the type specifier results in the given type.

Semantics

This judgment is specified by the following rules.

If the type is nillable, then it expands into an optional type.

statEnv |-  TypeReference expands to Type

statEnv |-  nillable TypeReference expands to Type?

The type definition for the type reference is contained in its expansion.

statEnv |-  TypeName of elem/type expands to expanded-QName

statEnv.typeDefn(expanded-QName) = define type TypeName extends BaseTypeName OptMixed { Type₁ }

statEnv |-  Type₂ is Type₁ extended with union interpretation of TypeName

statEnv |-  OptMixed Type₂ adjusts to Type₃

statEnv |-  of type TypeName expands to Type₃

In case the type is xs:untyped, the type does not need to be adjusted as is required for other XML Schema types. See the corresponding definition in [3.5.1 Predefined Schema Types].

statEnv |-  xs:untyped of elem/type expands to expanded-QName

statEnv.typeDefn(expanded-QName) = define type xs:untyped extends xs:anyType { Type₁ }

statEnv |-  of type xs:untyped expands to Type₁

8.1.10 Union interpretation of derived types

Notation

The judgment

statEnv |-  Type₂ is Type₁ extended with union interpretation of TypeName

holds when the type Type₂ is the expansion of the type name TypeName with definition Type₁ to include all types derived by extension and restriction from the given type name. This rule is recursive, because each type name itself may have other type names that are derived from it. The recursive rules traverse the entire derivation tree, identifying every type name derived from the original type name.

Semantics

This judgment is specified by the following rules.

No type derives from TypeName₀

statEnv |-  Type₀ is Type₀ extended with union interpretation of TypeName₀

statEnv.typeDefn(expanded-QNameR,1) = define type TypeNameR,1 restricts TypeName₀ OptMixedR,1 { TypeR,1 }

· · ·

statEnv.typeDefn(expanded-QNameR,n) = define type TypeNameR,n restricts TypeName₀ OptMixedR,n { TypeR,n }

statEnv |-  TypeR,1' is TypeR,1 extended with union interpretation of TypeNameR,1

· · ·

statEnv |-  TypeR,n' is TypeR,n extended with union interpretation of TypeNameR,n

statEnv.typeDefn(expanded-QNameE,1) = define type TypeNameE,1 extends TypeName₀ OptMixedE,1 { TypeE,1 }

· · ·

statEnv.typeDefn(expanded-QNameE,m) = define type TypeNameE,m extends TypeName₀ OptMixedE,m { TypeE,m }

statEnv |-  TypeE,1' is TypeE,1 extended with union interpretation of TypeNameE,1

· · ·

statEnv |-  TypeE,m' is TypeE,m extended with union interpretation of TypeNameE,m

Type₁ = TypeR,1' | · · · | TypeR,n' | Type₀ | (Type₀, TypeE,1' ) | · · · | (Type₀,TypeE,m')

statEnv |-  Type₁ is Type₀ extended with union interpretation of TypeName₀

Examples

Note that this expansion does not enforce the unique particule attribution property specified by XML Schema in the resulting content models. Implementations may want to implement an equivalent alternative expansion that enforces that property. For example, expanding type T1 below yields the following type that is not one-deterministic:

define type T1 { element a }
define type T2 extends T1 { element b }

(element a | element a, element b) is (element a) extended with union interpretation of T1

An implementation might want to infer the equivalent content model that verifies the unique particule attribution property of XML Schema:

(element a, (() | element b)) is (element a) extended with union interpretation of T1

8.2 Judgments for step expressions and filtering

Introduction

Step expressions are one of the elementary operations in [XPath/XQuery]. Steps select nodes reachable from the root of an XML tree. Defining the semantics of step expressions requires a detailed analysis of all the possible cases of axis and node tests.

This section introduces auxiliary judgments used to define the semantics of step expressions. The has principal judgment ([8.2.1 Principal Node Kind]) captures the notion of principal node kind in XPath. The Axis judgments ([8.2.2 Auxiliary judgments for axes]) define the static and dynamic semantics of all axes, and the Node Test judgments ([8.2.3 Auxiliary judgments for node tests]) define the static and dynamic semantics of all node tests. The filter judgment accesses the value of an attribute and is used in the definition of validation ([F Auxiliary Judgments for Validation]).

8.2.1 Principal Node Kind

Notation

The following auxiliary grammar production describes principal node kinds (See [XML Path Language (XPath) 2.0]).

PrincipalNodeKind

[64 (Formal)]   
PrincipalNodeKind
   ::=   
"element" | "attribute" | "namespace"

Notation

The judgment

Axis has principal PrincipalNodeKind

holds when PrincipalNodeKind is the principal node kind for Axis.

Example

For example, the following judgments hold.

  child::       principal  element
  descendant::  principal  element
  preceding::   principal  element
  attribute::   principal  attribute
  namespace::   principal  namespace

Semantics

This judgment is specified by the following rules.

The principal node type for the attribute axis is attribute.

attribute:: has principal attribute

The principal node type for the namespace axis is namespace.

namespace:: has principal namespace

The principal node type for all other axis is element.

Axis != attribute::     Axis != namespace::

Axis has principal element

8.2.2 Auxiliary judgments for axes

8.2.2.1 Static semantics of axes

Notation

The following judgment

statEnv |-  axis Axis of Type₁ : Type₂

holds when applying the axis Axis on type Type₁ yields the type Type₂.

The following two judgments are used in the definition of axis. The judgment

statEnv |-  Type₁ has node content Type₂

only applies to a type that is a valid element content type and holds when Type₁ has the content type Type₂. The judgment separates the attribute types from the other node or atomic-valued types of the element content type and yields the non-attribute types.

The judgment

statEnv |-  Type₁ has attribute content Type₂

only applies to a type that is a valid element content type and holds when Type₁ has attribute types Type₂. The judgment yields the attribute types of the element content type.

Example

For example, the following judgments hold.

  axis child::      of  element of type xs:string   :  text
  axis child::      of  element items of type Items :  element item of type fs:anon1*

  axis child::      of  element purchaseOrder       :
    element shipTo of type USAddress,
    element billTo of type USAddress,
    element ipo:comment?,
    element items of type Items

  axis attribute::  of  element of type xs:string   :  empty

    attribute partNum of type SKU,
    element item of type fs:anon1*
  has-node-content
    element item of type fs:anon1*

    attribute partNum of type SKU,
    element item of type fs:anon1*
  has-attribute-content
    attribute partNum of type SKU

    (attribute partNum of type SKU,
     element item of type fs:anon1*) |
    (attribute orderDate of type xs:date?,
     element shipTo of type USAddress,
     element billTo of type USAddress,
     element comment?,
     element items of type Items)
  has-node-content
    (element item of type fs:anon1*) |
    (element shipTo of type USAddress,
     element billTo of type USAddress,
     element comment?,
     element items of type Items)

    (attribute partNum of type SKU,
     element item of type fs:anon1*) |
    (attribute orderDate of type xs:date?,
     element shipTo of type USAddress,
     element billTo of type USAddress,
     element comment?,
     element items of type Items)
  has-attribute-content
    (attribute partNum of type SKU) |
    (attribute orderDate of type xs:date?)

8.2.2.1.1 Inference rules for all axes

Semantics

The following rules compute the type of the axis expression when applied to each item type in the content model.

statEnv |-  axis Axis of Type₁ : Type₂

statEnv |-  axis Axis of Type₁ OccurrenceIndicator : Type₂ OccurrenceIndicator

statEnv |-  axis Axis of Type₁ : Type₃

statEnv |-  axis Axis of Type₂ : Type₄

statEnv |-  axis Axis of Type₁&Type₂ : Type₃&Type₄

statEnv |-  axis Axis of Type₁ : Type₃

statEnv |-  axis Axis of Type₂ : Type₄

statEnv |-  axis Axis of Type₁,Type₂ : Type₃,Type₄

statEnv |-  axis Axis of Type₁ : Type₃

statEnv |-  axis Axis of Type₂ : Type₄

statEnv |-  axis Axis of Type₁|Type₂ : Type₃|Type₄

statEnv |-  axis Axis of none : none

statEnv |-  axis Axis of empty : empty

The rules in the following subsections specify how to compute the type of each axis applied to an item type.

8.2.2.1.2 Inference rules for the self axis

Semantics

Applying the self axis to a node type results in the same node type.

statEnv |-  axis self:: of NodeType : NodeType

8.2.2.1.3 Inference rules for the child axis

Semantics

In the case of an element type, the static type of the child axis is obtained by type lookup and expansion of the resulting type. Note that the expands to judgment yields the type that corresponds to a given type name. Because the meaning of a type name includes the definitions of all type names derived by extension and restriction from the given type name, expands to yields the union of all the type definitions of all type names derived from the input type name. Each type in the union contains the complete definition of the type name, i.e., it includes built-in attributes and, if necessary, processing-instruction, comment, and text types.

After type expansion, the judgment has node content is applied to each type in the union. The resulting type is the union of all non-attribute types in the expanded type.

statEnv |-  ElementType type lookup OptNillable TypeReference

statEnv |-  OptNillable TypeReference expands to Type₁ | · · · | Typen

statEnv |-  Type₁ has node content Type₁'

· · ·

statEnv |-  Typen has node content Typen'

statEnv |-  axis child:: of ElementType : Type₁' | ... | Typen'

If the type is a sequence of attributes, then the content type is empty.

statEnv |-  Type <: attribute*

statEnv |-  Type has node content empty

If the type is attributes followed by a simple type, the content type is zero-or-one text nodes. The resulting type is optional since an expression returning the empty sequence results in no text node being constructed.

Type = Type₁, Type₂

statEnv |-  Type₁ <: attribute*

statEnv |-  Type₂ <: xs:anyAtomicType*

statEnv |-  Type has node content text?

In the case of an element type with complex content type, the content type is simply the non-attribute part of the complex content type.

Type = Type₁, Type₂

statEnv |-  Type₁ <: attribute*

statEnv |-  Type₂ <: ElementModel*

statEnv |-  Type has node content Type₂

In the case of an attribute type, the static type of the child axis is empty.

statEnv |-  axis child:: of AttributeType : empty

In the case of a text node type, the static type of the child axis is empty.

statEnv |-  axis child:: of text : empty

In the case of a comment node type, the static type of the child axis is empty.

statEnv |-  axis child:: of comment : empty

In the case of a processing-instruction node type, the static type of the child axis is empty.

statEnv |-  axis child:: of processing-instruction : empty

In case of a document node type, the static type of the child axis is the type of the document node content, interleaved with a sequence of comments and processing-instructions.

statEnv |-  axis child:: of document { Type } : Type & processing-instruction* & comment*

8.2.2.1.4 Inference rules for the attribute axis

Semantics

The static type for the attribute axis is computed in a similar way as the static type for the child axis. As above, the expands to judgment may yield a union type. After type expansion, the judgment has attribute content is applied to each type in the union.

statEnv |-  ElementType type lookup OptNillable TypeReference

statEnv |-  OptNillable TypeReference expands to Type₁ | · · · | Typen

statEnv |-  Type₁ has attribute content Type₁'

· · ·

statEnv |-  Typen has attribute content Typen'

statEnv |-  axis attribute:: of ElementType : Type₁' | ... | Typen'

When applied to an element type, has attribute content yields the type of the element's content that are attributes.

Type = (Type₁, Type₂)

statEnv |-  Type₁ <: attribute*

statEnv |-  Type₂ <: ElementModel* | xs:anyAtomicType*

statEnv |-  Type has attribute content Type₁

In case of an attribute type, the static type of the attribute axis is empty.

statEnv |-  axis attribute:: of AttributeType : empty

In case of a text node type, the static type of the attribute axis is empty.

statEnv |-  axis attribute:: of text : empty

In case of a comment node type, the static type of the attribute axis is empty.

statEnv |-  axis attribute:: of comment : empty

In case of a processing-instruction node type, the static type of the attribute axis is empty.

statEnv |-  axis attribute:: of processing-instruction : empty

In case of a document node type, the static type of the attribute axis is the empty.

statEnv |-  axis attribute:: of document { Type } : empty

8.2.2.1.5 Inference rules for the parent axis

Semantics

The type for the parent of an element type, a text node type, a PI node type, or a comment node type is either an element, a document, or empty.

statEnv |-  axis parent:: of element : (element | document)?

statEnv |-  axis parent:: of text : (element | document)?

statEnv |-  axis parent:: of processing-instruction : (element | document)?

statEnv |-  axis parent:: of comment : (element | document)?

The type for the parent of an attribute node is an element or empty.

statEnv |-  axis parent:: of AttributeType : element?

The type for the parent of a document node type is always empty.

statEnv |-  axis parent:: of DocumentType : empty

8.2.2.1.6 Inference rules for the namespace axis

Semantics

The type for the namespace axis is always empty.

statEnv |-  axis namespace:: of NodeType : empty

8.2.2.1.7 Inference rules for the descendant axis

Semantics

The types for the descendant axis is obtained as the closure of the type of the child axis. This is expressed by the following inference rule.

statEnv |-  axis child:: of Type : Type₁

statEnv |-  axis child:: of prime(Type₁) : Type₂

...

statEnv |-  axis child:: of prime(Typen) : Typen+1

statEnv |-  prime(Typen+1) <: prime(Type₁) | ... | prime(Typen)

statEnv |-  axis descendant:: of Type : (prime(Type₁) | ... | prime(Typen))*

Note

Note that the last premise in the above rule terminates the recursion. The rule computes the n-th type Typen such that applying the child axis one more time does not add any new item type to the union. This condition is guaranteed to hold at some point, because the number of item types is bounded by all of the item types defined in the in-scope schema definitions.

8.2.2.1.8 Inference rules for the descendant-or-self axis

Semantics

The type for the descendant-or-self axis is the union of the type for the self axis and for the descendant axis.

statEnv |-  axis descendant:: of Type₁ : Type₂

statEnv |-  axis descendant-or-self:: of Type₁ : (prime(Type₁) | prime(Type₂))*

8.2.2.1.9 Inference rules for the ancestor axis

Semantics

The type for the ancestor axis is computed similarly as for the descendant axis.

statEnv |-  axis ancestor:: of NodeType : (element | document)*

Note that this rule will always result in the type (element | document)* type, but this formulation is preferred for consistency, and in case the static typing for the parent axis gets improved in a future version.

statEnv |-  axis parent:: of Type : Type₁

statEnv |-  axis parent:: of prime(Type₁) : Type₂

...

statEnv |-  axis parent:: of prime(Typen) : Typen+1

statEnv |-  prime(Typen+1) <: prime(Type₁) | ... | prime(Typen)

statEnv |-  axis ancestor:: of Type : (prime(Type₁) | ... | prime(Typen))*

8.2.2.1.10 Inference rules for the ancestor-or-self axis

Semantics

The type for the ancestor-or-self axis is the union of the type for the self axis and for the ancestor axis.

statEnv |-  axis ancestor:: of Type₁ : Type₂

statEnv |-  axis ancestor-or-self:: of Type₁ : (prime(Type₁) | prime(Type₂))*

8.2.2.2 Dynamic semantics of axes

Notation

The following judgment

dynEnv |-  axis Axis of Value₁ => Value₂

holds when applying the axis Axis on Value₁ yields Value₂:

Example

For example, the following judgments hold.

  axis child::      of    element sizes { text { "1 2 3" } }  =>  text { "1 2 3" }

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

Semantics

This judgment is specified by the following rules.

The first set of rules are used to process the axis judgment on each individual item in the input sequence.

dynEnv |-  axis Axis of () => ()

dynEnv |-  axis Axis of Value₁ => Value₃

dynEnv |-  axis Axis of Value₂ => Value₄

dynEnv |-  axis Axis of Value₁,Value₂ => Value₃,Value₄

The following rules specifies how the value filter judgment is applied on each Axis.

The self axis just returns the context node.

dynEnv |-  axis self:: of NodeValue => NodeValue

The child, parent, attribute and namespace axis are specified as follows.

dynEnv |-  axis child:: of element ElementName { AttributeValue,ElementValue } => ElementValue

dynEnv |-  axis attribute:: of element ElementName { AttributeValue,ElementValue } => AttributeValue

dynEnv |-  axis parent:: of NodeValue => dm:parent(NodeValue)

The descendant, descendant-or-self, ancestor, and ancestor-or-self axis are implemented through recursive application of the children and parent filters.

dynEnv |-  axis child:: of NodeValue => Value₁

dynEnv |-  axis descendant:: of Value₁ => Value₂

dynEnv |-  axis descendant:: of NodeValue => Value₁, Value₂

dynEnv |-  axis self:: of NodeValue => Value₁

dynEnv |-  axis descendant:: of Value₁ => Value₂

dynEnv |-  axis descendant-or-self:: of NodeValue => Value₁, Value₂

dynEnv |-  axis parent:: of NodeValue => Value₁

dynEnv |-  axis ancestor:: of Value₁ => Value₂

dynEnv |-  axis ancestor:: of NodeValue => Value₁, Value₂

dynEnv |-  axis self:: of NodeValue => Value₁

dynEnv |-  axis ancestor:: of Value₁ => Value₂

dynEnv |-  axis ancestor-or-self:: of NodeValue => Value₁, Value₂

In all the other cases, the axis application results in an empty sequence, and the following judgment holds.

dynEnv |-  axis Axis of NodeValue => ()

8.2.3 Auxiliary judgments for node tests

A node test may be a name test or a kind test. In the static and dynamic semantics, we begin with name tests, followed by kind tests.

8.2.3.1 Static semantics of node tests

Notation

The following judgment

statEnv |-  test NodeTest with PrincipalNodeKind of Type₁ : Type₂

holds when applying the node test NodeTest on the type Type₁ in the context of the given principal node kind, yields the type Type₂.

Example

For example, assuming the extended XML Schema given in section [2.4.5 Example of a complete Schema], then the following judgments hold.

  test shipTo with element of
    element shipTo of type USAddress,
    element billTo of type USAddress,
    element ipo:comment?,
    element items of type Items
  : element shipTo of type USAddress

Semantics

This judgment is specified by the following rules.

The first set of rules is similar to that for axes, and are used to process the content each individual item type in the input content model.

statEnv |-  test NodeTest with PrincipalNodeKind of Type₁ : Type₂

statEnv |-  test NodeTest with PrincipalNodeKind of Type₁ OccurrenceIndicator : Type₂ OccurrenceIndicator

statEnv |-  test NodeTest with PrincipalNodeKind of Type₁ : Type₃

statEnv |-  test NodeTest with PrincipalNodeKind of Type₂ : Type₄

statEnv |-  test NodeTest with PrincipalNodeKind of Type₁ & Type₂ : Type₃ & Type₄

statEnv |-  test NodeTest with PrincipalNodeKind of Type₁ : Type₃

statEnv |-  test NodeTest with PrincipalNodeKind of Type₂ : Type₄

statEnv |-  test NodeTest with PrincipalNodeKind of Type₁ , Type₂ : Type₃ , Type₄

statEnv |-  test NodeTest with PrincipalNodeKind of Type₁ : Type₃

statEnv |-  test NodeTest with PrincipalNodeKind of Type₂ : Type₄

statEnv |-  test NodeTest with PrincipalNodeKind of Type₁|Type₂ : Type₃|Type₄

statEnv |-  test NodeTest with PrincipalNodeKind of none : none

statEnv |-  test NodeTest with PrincipalNodeKind of empty : empty

The following rules specify how the test judgment apply to node tests in the context of a principal node kind. We start with name tests followed by kind tests.

8.2.3.1.1 Name Tests

Name tests on elements and attributes always compute the most specific type possible. For example, if $v is bound to an element with a computed name, the type of $v is element. The static type computed for the expression $v/self::foo is element foo of type xs:anyType, which makes use of foo in the name test to compute a more specific type. Also note that each case of name matching restricts the principal node kind appropriately.

statEnv |-  QName₁ of elem/type expands to expanded-QName

statEnv |-  QName₂ of elem/type expands to expanded-QName

statEnv |-  test QName₂ with element of element QName₁ OptTypeSpecifier : element QName₁ OptTypeSpecifier

statEnv |-  test QName₂ with element of element * OptTypeSpecifier : element QName₂ OptTypeSpecifier

statEnv |-  test QName₂ with element of element OptTypeSpecifier : element QName₂ OptTypeSpecifier

statEnv |-  QName₁ of elem/type expands to expanded-QName₁

statEnv.namespace(Prefix₁) = (NamespaceKind,AnyURI)

fn:namespace-uri-from-QName(expanded-QName₁) = AnyURI

LocalPart₂ = fn:local-name-from-QName( expanded-QName₁ )

statEnv |-  test *:LocalPart₂ with element of element QName₁ OptTypeSpecifier : element QName₁ OptTypeSpecifier

statEnv |-  test *:LocalPart₂ with element of element * OptTypeSpecifier : element *:LocalPart₂ OptTypeSpecifier

statEnv |-  QName₁ of elem/type expands to expanded-QName₁

statEnv.namespace(Prefix₁) = (NamespaceKind,AnyURI)

fn:namespace-uri-from-QName(expanded-QName₁) = AnyURI

statEnv |-  test Prefix₂:* with element of element QName₁ OptTypeSpecifier : element QName₁ OptTypeSpecifier

statEnv |-  test Prefix₂:* with element of element * OptTypeSpecifier : element Prefix₂:* OptTypeSpecifier

statEnv |-  test * with element of element QName OptTypeSpecifier : element QName OptTypeSpecifier

Similar static typing rules apply to the attribute name tests:

statEnv |-  QName₁ of attr expands to expanded-QName

statEnv |-  QName₂ of attr expands to expanded-QName

statEnv |-  test QName₂ with attribute of attribute QName₁ OptTypeReference : attribute QName₁ OptTypeReference

statEnv |-  test QName₂ with attribute of attribute * OptTypeReference : attribute QName₂ OptTypeReference

statEnv |-  test QName₂ with attribute of attribute OptTypeReference : attribute QName₂ OptTypeReference

statEnv |-  QName₁ of attr expands to expanded-QName₁

fn:local-name-from-QName( expanded-QName₁ ) = LocalPart₂

statEnv |-  test *:LocalPart₂ with attribute of attribute QName₁ OptTypeReference : attribute QName₁ OptTypeReference

statEnv |-  test *:LocalPart₂ with attribute of attribute * OptTypeReference : attribute *:LocalPart₂ OptTypeReference

statEnv.namespace(Prefix₂) = (NamespaceKind,AnyURI)

statEnv |-  QName₁ of elem/type expands to expanded-QName₁

fn:namespace-uri-from-QName(expanded-QName₁) = AnyURI

statEnv |-  test Prefix₂:* with attribute of attribute QName₁ OptTypeReference : attribute QName₁ OptTypeReference

statEnv |-  test Prefix₂:* with attribute of attribute * OptTypeReference : attribute Prefix₂:* OptTypeReference

statEnv |-  test * with attribute of attribute QName OptTypeReference : attribute QName OptTypeReference

Lastly, if none of the above rules holds, then the type of the input expression is empty.

ElementNameOrWildcard 1 = NameTest

TypeSpecifier₁ = of type xs:anyType

statEnv |-  not(element ElementNameOrWildcard 1 TypeSpecifier₁ <: element ElementNameOrWildcard 2 TypeSpecifier₂)

statEnv |-  not(element ElementNameOrWildcard 2 TypeSpecifier₂ <: element ElementNameOrWildcard 1 TypeSpecifier₁)

statEnv |-  TypeSpecifier₁ expands to Type₁

statEnv |-  TypeSpecifier₂ expands to Type₂

statEnv |-  not(Type₁ <: Type₂)

statEnv |-  not(Type₂ <: Type₁)

statEnv |-  test NameTest with element of element ElementNameOrWildcard 2 TypeSpecifier₂ : empty

8.2.3.1.2 Kind Tests

All the rules for typing the document, element, and attribute kind tests are similar. First, the document, element, or attribute test is normalized to the equivalent document, element, or attribute type by applying the []sequencetype normalization rule to the kind test.

After normalization of the kind test as an XQuery type, that type is compared to the expression's inferred type. If the latter is a subtype of the former other, then the kind test yields the smaller type.

Document kind test

Semantics

If the type of the expression is a subtype of the document kind test, then we are guaranteed that during evaluation, the expression's value will always match the document kind test, and therefore the type of the entire expression is the type of the input expression.

[DocumentTest]sequencetype = DocumentType

statEnv |-  Type₁ <: DocumentType

statEnv |-  test DocumentTest with element of Type₁ : Type₁

Conversely, if the type of the document kind test is a subtype of the expression, then during evaluation, the expression's value may or may not match the document kind test, and therefore the type of the entire expression is zero-or-one of the type of the document kind test.

[DocumentTest]sequencetype = DocumentType

statEnv |-  DocumentType <: Type₁

statEnv |-  test DocumentTest with element of Type₁ : DocumentType?

If the types of the expression and document kind test are unrelated, then we apply the kind test rule recursively on the element types, which may yield a non-empty type.

[document-node (ElementTest)]sequencetype = DocumentType

statEnv |-  not(Type₁ <: DocumentType)

statEnv |-  not(DocumentType <: Type₁)

statEnv |-  test ElementTest with element of Type₁ : Type₂      statEnv |-  not(Type₂ <: empty)

statEnv |-  test document-node (ElementTest) with element of document { Type₁ } : document { Type₂ }

If there is no non-empty type, then the kind test yields the empty type.

[document-node (ElementTest)]sequencetype = DocumentType

statEnv |-  not(Type₁ <: DocumentType)

statEnv |-  not(DocumentType <: Type₁)

statEnv |-  test ElementTest with element of Type₁ : Type₂

statEnv |-  Type₂ <: empty

statEnv |-  test document-node (ElementTest) with element of document { Type₁ } : empty

Element kind test

Semantics

The rules for the element kind test are similar to those for the document kind test.

If the type of the expression is a subtype of the element kind test, then we are guaranteed that during evaluation, the expression's element value will always match the element kind test, and therefore the type of the entire expression is the type of the input expression.

[ElementTest]sequencetype = ElementType

statEnv |-  Type₁ <: ElementType

statEnv |-  test ElementTest with element of Type₁ : Type₁

Conversely, if the type of the element kind test is a subtype of the expression, then during evaluation, the expression's element value may or may not match the element kind test, and therefore the type of the entire expression is zero-or-one of the type of the element kind test.

[ElementTest]sequencetype = ElementType

statEnv |-  ElementType <: Type₁

statEnv |-  test ElementTest with element of Type₁ : ElementType?

If the types of the expression and element kind test are unrelated (i.e., neither type is a subtype of the other), then we must compare the structure of the type of the element test with the type of the element expression, as an element type or test may contain wildcards.

In the first case, the element kind test contains an element name and a type name and the input expression's type contains only a type name. If the input expression's content type is a subtype of the element kind test's content type, then the type of the entire expression is zero-or-one of an element with the given name and the input expression's content type.

[ElementTest]sequencetype = element ElementName₁ TypeSpecifier₁      statEnv |-  TypeSpecifier₁ expands to Type₁

statEnv |-  TypeSpecifier₂ expands to Type₂

statEnv |-  Type₂ <: Type₁

statEnv |-  test ElementTest with element of element TypeSpecifier₂ : element ElementName₁ TypeSpecifier₂?

In the second case, the structure of the input types is reversed: The input expression's type contains an element name and a type name and the element kind test's type contains only a type name. If the element kind test's content type is a subtype of the input expression's content type, then the type of the entire expression is zero-or-one of an element with the given name and the element kind test's content type.

[ElementTest]sequencetype = element TypeSpecifier₁      statEnv |-  TypeSpecifier₁ expands to Type₁

statEnv |-  TypeSpecifier₂ expands to Type₂

statEnv |-  Type₁ <: Type₂

statEnv |-  test ElementTest with element of element ElementName₂ TypeSpecifier₂ : element ElementName₂ TypeSpecifier₁?

Lastly, if none of the above rules holds, then the type of the input expression is empty.

[ElementTest]sequencetype = element ElementNameOrWildcard 1 TypeSpecifier₁

statEnv |-  not(element ElementNameOrWildcard 1 TypeSpecifier₁ <: element ElementNameOrWildcard 2 TypeSpecifier₂)

statEnv |-  not(element ElementNameOrWildcard 2 TypeSpecifier₂ <: element ElementNameOrWildcard 1 TypeSpecifier₁)

statEnv |-  TypeSpecifier₁ expands to Type₁

statEnv |-  TypeSpecifier₂ expands to Type₂

statEnv |-  not(Type₁ <: Type₂)

statEnv |-  not(Type₂ <: Type₁)

statEnv |-  test ElementTest with element of element ElementNameOrWildcard 2 TypeSpecifier₂ : empty

Attribute kind test

Semantics

The rules for the attribute kind test are isomorphic to those for element kind test.

If the type of the expression is a subtype of the attribute kind test, then we are guaranteed that during evaluation, the expression's attribute value will always match the attribute kind test, and therefore the type of the entire expression is the type of the input expression.

[AttributeTest]sequencetype = AttributeType

statEnv |-  Type₁ <: AttributeType

statEnv |-  test AttributeTest with attribute of Type₁ : Type₁

Conversely, if the type of the attribute kind test is a subtype of the expression, then during evaluation, the expression's attribute value may or may not match the attribute kind test, and therefore the type of the entire expression is zero-or-one of the type of the attribute kind test.

[AttributeTest]sequencetype = AttributeType

statEnv |-  AttributeType <: Type₁

statEnv |-  test AttributeTest with attribute of Type₁ : AttributeType?

If the types of the expression and attribute kind test are unrelated (i.e., neither type is a subtype of the other), then we must compare the structure of the type of the attribute test with the type of the attribute expression, as an attribute type or test may contain wildcards.

In the first case, the attribute kind test contains an attribute name and a type name and the input expression's type contains only a type name. If the input expression's content type is a subtype of the attribute kind test's content type, then the type of the entire expression is zero-or-one of an attribute with the given name and the input expression's content type.

[AttributeTest]sequencetype = attribute AttributeName₁ TypeReference₁      statEnv |-  TypeReference₁ expands to Type₁

statEnv |-  TypeReference₂ expands to Type₂

statEnv |-  Type₂ <: Type₁

statEnv |-  test AttributeTest with attribute of attribute TypeReference₂ : attribute AttributeName₁ TypeReference₂?

In the second case, the structure of the input types is reversed: The input expression's type contains an attribute name and a type name and the attribute kind test's type contains only a type name. If the attribute kind test's content type is a subtype of the input expression's content type, then the type of the entire expression is zero-or-one of an attribute with the given name and the attribute kind test's content type.

[AttributeTest]sequencetype = attribute TypeReference₁      statEnv |-  TypeReference₁ expands to Type₁

statEnv |-  TypeReference₂ expands to Type₂

statEnv |-  Type₁ <: Type₂

statEnv |-  test AttributeTest with attribute of attribute AttributeName₂ TypeReference₂ : attribute AttributeName₂ TypeReference₁?

Lastly, if none of the above rules holds, then the type of the input expression is empty.

[AttributeTest]sequencetype = attribute AttributeName 1 TypeReference₁

statEnv |-  not(attribute AttributeName 1 TypeReference₁ <: attribute AttributeName 2 TypeReference₂)

statEnv |-  not(attribute AttributeName 2 TypeReference₂ <: attribute AttributeName 1 TypeReference₁)

statEnv |-  TypeReference₁ expands to Type₁

statEnv |-  TypeReference₂ expands to Type₂

statEnv |-  not(Type₁ <: Type₂)

statEnv |-  not(Type₂ <: Type₁)

statEnv |-  test AttributeTest with attribute of attribute AttributeName 2 TypeReference₂ : empty

Processing instruction, comment, and text kind tests

Semantics

statEnv |-  test processing-instruction() with PrincipalNodeKind of processing-instruction : processing-instruction

A processing-instruction node test with a string literal or NCName matches a processing instruction whose target has the given name. Since target matching cannot be checked statically, the static type of the node test is zero-or-one processing instruction.

statEnv |-  test processing-instruction(StringLiteral | NCName) with PrincipalNodeKind of processing-instruction : processing-instruction?

statEnv |-  test comment() with PrincipalNodeKind of comment : comment

statEnv |-  test text() with PrincipalNodeKind of text : text

statEnv |-  test node() with PrincipalNodeKind of NodeType : NodeType

If none of the above rules applies then the node test returns the empty sequence, and the following dynamic rule is applied:

Otherwise

statEnv |-  test NodeTest with PrincipalNodeKind of NodeType : empty

8.2.3.2 Dynamic semantics of node tests

Notation

The following judgment

dynEnv |-  test NodeTest with PrincipalNodeKind of Value₁ => Value₂

holds when applying the node test NodeTest on Value₁ in the context of the PrincipalNodeKind yields Value₂:

Example

For example, the following judgments hold.

  test node()  with element  of    text { "1 2 3" }  => text { "1 2 3" }
  test size    with element  of    text { "1 2 3" }  => ()

  test foo:*   with element  of
     (element foo:a of type xs:int { 1 },
      element foo:a of type xs:int { 2 },
      element bar:b of type xs:int { 3 },
      element bar:c of type xs:int { 4 },
      element foo:d of type xs:int { 5 })
  => (element foo:a of type xs:int { 1 },
      element foo:a of type xs:int { 2 },
      (),
      (),
      element foo:d of type xs:int { 5 })

Note

The last example illustrates how a test judgment operates on a sequence of nodes, applying the test on each node in the sequence individually, while preserving the structure of the sequence.

Semantics

This judgment is specified by the following rules.

The first set of rules are similar to those for axes, and are used to process the test judgment on each individual item in the input sequence.

dynEnv |-  test NodeTest with PrincipalNodeKind of () => ()

dynEnv |-  test NodeTest with PrincipalNodeKind of Value₁ => Value₃

dynEnv |-  test NodeTest with PrincipalNodeKind of Value₂ => Value₄

dynEnv |-  test NodeTest with PrincipalNodeKind of Value₁,Value₂ => Value₃,Value₄

8.2.3.2.1 Name Tests

The following rules specify how the value filter judgment is applied on a name test in the context of a principal node kind.

Semantics

dm:node-kind( NodeValue ) = PrincipalNodeKind

fn:node-name( NodeValue ) = expanded-QName

statEnv.namespace(Prefix) = (NamespaceKind,AnyURI)

fn:namespace-uri-from-QName(expanded-QName) = AnyURI

fn:local-name-from-QName( expanded-QName ) = LocalPart

dynEnv |-  test Prefix:LocalPart with PrincipalNodeKind of NodeValue => NodeValue

dm:node-kind( NodeValue ) = PrincipalNodeKind

dynEnv |-  test * with PrincipalNodeKind of NodeValue => NodeValue

dm:node-kind( NodeValue ) = PrincipalNodeKind

fn:node-name ( NodeValue ) = expanded-QName

statEnv.namespace(Prefix) = (NamespaceKind,AnyURI)

fn:namespace-uri-from-QName(expanded-QName) = AnyURI

dynEnv |-  test Prefix:* with PrincipalNodeKind of NodeValue => NodeValue

dm:node-kind( NodeValue ) = PrincipalNodeKind

fn:node-name ( NodeValue ) = expanded-QName

fn:local-name-from-QName ( expanded-QName ) = LocalPart

dynEnv |-  test *:LocalPart with PrincipalNodeKind of NodeValue => NodeValue

8.2.3.2.2 Kind Tests

All the rules for evaluating the document, element, and attribute kind tests are similar. First, the document, element, or attribute test is normalized to the equivalent document, element, or attribute type by applying the []sequencetype normalization rule. As explained in [3.5.3 SequenceType Syntax], SequenceTypes are normalized to XQuery types whenever a dynamic evaluation or static typing rule requires the corresponding type. The reason for this deviation from the processing model is that the result of SequenceType normalization is not part of the [XPath/XQuery] core syntax.

After normalization of the SequenceType to an XQuery type, the document, element, or attribute value is simply matched against the XQuery type. If the value matches the type, then the judgment yields the value, otherwise the judgment yields the empty sequence.

Document kind test

Semantics

[DocumentTest]sequencetype = DocumentType

statEnv |-  DocumentValue matches DocumentType

dynEnv |-  test DocumentTest with element of DocumentValue => DocumentValue

[DocumentTest]sequencetype = DocumentType

statEnv |-  not(DocumentValue matches DocumentType)

dynEnv |-  test DocumentTest with element of DocumentValue => ()

Element kind test

Semantics

[ElementTest]sequencetype = ElementType

statEnv |-  ElementValue matches ElementType

dynEnv |-  test ElementTest with element of ElementValue => ElementValue

[ElementTest]sequencetype = ElementType

statEnv |-  not(ElementValue matches ElementType)

dynEnv |-  test ElementTest with element of ElementValue => ()

Attribute kind test

Semantics

[AttributeTest]sequencetype = AttributeType

statEnv |-  AttributeValue matches AttributeType

dynEnv |-  test AttributeTest with attribute of AttributeValue => AttributeValue

[AttributeTest]sequencetype = AttributeType

statEnv |-  not(AttributeValue matches AttributeType)

dynEnv |-  test AttributeTest with attribute of AttributeValue => ()

Processing instruction, comment, and text kind tests

Semantics

dm:node-kind ( NodeValue ) = "processing-instruction"

dynEnv |-  test processing-instruction() with PrincipalNodeKind of NodeValue => NodeValue

dm:node-kind ( NodeValue ) = "processing-instruction"

fn:node-name ( NodeValue ) = expanded-QName

dynEnv |-  StringLiteral has atomic value String

fn:local-name-from-QName ( expanded-QName ) = String

dynEnv |-  test processing-instruction( StringLiteral ) with PrincipalNodeKind of NodeValue => NodeValue

not(dm:node-kind ( NodeValue ) = "processing-instruction")

dynEnv |-  test processing-instruction() with PrincipalNodeKind of NodeValue => ()

dm:node-kind ( NodeValue ) = "comment"

dynEnv |-  test comment() with PrincipalNodeKind of NodeValue => NodeValue

not(dm:node-kind ( NodeValue ) = "comment")

dynEnv |-  test comment() with PrincipalNodeKind of NodeValue => ()

dm:node-kind ( NodeValue ) = "text"

dynEnv |-  test text() with PrincipalNodeKind of NodeValue => NodeValue

not(dm:node-kind ( NodeValue ) = "text")

dynEnv |-  test text() with PrincipalNodeKind of NodeValue => ()

The node() node test is true for all nodes. Therefore, the following rule does not have any precondition (remember that an empty upper part in the rule indicates that the rule is always true).

dynEnv |-  test node() with PrincipalNodeKind of NodeValue => NodeValue

If none of the above rules applies then the node test returns the empty sequence, and the following dynamic rule is applied:

Otherwise

dynEnv |-  test NodeTest with PrincipalNodeKind of NodeValue => ()

8.3 Judgments for type matching

Introduction

XQuery supports type declarations on variable bindings, and several operations on types (typeswitch, instance of, etc). This section describes judgments used for the specification of the semantics of those operations.

The "match" judgment specifies formally type matching. It takes as input a value and a type and either succeeds or fails. It is used in matching parameters against function signatures, type declarations, and matching values against cases in "typeswitch". An informal description of type matching is given in Section 2.5.4 SequenceType MatchingXQ.

The "subtyping" judgment takes two types and succeeds if all values matching the first type also match the second. It is used to define the static semantics of operations using type matching.

8.3.1 Matches

Notation

The judgment

statEnv |-  Value matches Type

holds when the given value matches the given type.

Example

For example, assuming the extended XML Schema given in section [2.4.5 Example of a complete Schema], then the following judgments hold.

  element comment of type xsd:string { "This is not important" }
    matches
  element comment of type xsd:string

  (element apt of type fs:anon3 { 2510 },
   element apt of type fs:anon3 { 2511 })
    matches
  element apt+

  ()
    matches
  element usaddress?

  element usaddress of type USAddress {
    element name of type xsd:string { "The Archive" },
    element street of type xsd:string { "Christopher Street" },
    element city of type xsd:string { "New York" },
    element state of type xsd:string { "NY" },
    element zip of type xsd:decimal { 10210 }
  }
    matches
  element usaddress?

Semantics

We start by giving the inference rules for matching an item value with an item type.

An atomic value matches an atomic type if its type annotationXQ derives from the atomic type. The value itself is ignored -- this is checked as part of validation.

statEnv |-  AtomicTypeName 1 derives from AtomicTypeName 2

statEnv |-  AtomicValueContent of type AtomicTypeName 1 matches AtomicTypeName 2

A text node matches text.

statEnv |-  text { String } matches text

A comment node matches comment.

statEnv |-  comment { String } matches comment

A processing-instruction node matches processing-instruction.

statEnv |-  processing-instruction NCName { String } matches processing-instruction

A document node matches a document type if the node's content matches the document type's corresponding content type.

statEnv |-  Value matches Type

statEnv |-  document { Value } matches document { Type }

The rules for matching an element value with an element type are more complicated. When an element value is not nilled, the element matches an element type if the element name and the element type resolve to some type name, and the element value's type annotationXQ is derived from the resolved type name. Note that there is no need to check structural constraints on the value since those have been checked during XML Schema validation and the value is assumed to be consistent with its type annotationXQ.

statEnv |-  ElementName name lookup ElementType yields OptNillable of type BaseTypeName

statEnv |-  TypeName derives from BaseTypeName

Value₁ filter @xsi:nil => SimpleValue

SimpleValue in { (), false }

statEnv |-  element ElementName of type TypeName { Value } matches ElementType

Note

Type matching uses the name lookup judgment defined in [8.1.3 Element and attribute name lookup (Dynamic)].

In the case the element has been nilled, that is there exists and xsi:nil attribute set to true in the element value, the following rule checks that the type is nillable.

statEnv |-  ElementName name lookup ElementType yields nillable of type BaseTypeName

statEnv |-  TypeName derives from BaseTypeName

Value filter @xsi:nil => true

statEnv |-  element ElementName of type TypeName { Value } matches ElementType

The rule for attributes is similar, but does not require the check for the xsi:nil attribute.

statEnv |-  AttributeName name lookup AttributeType yields of type BaseTypeName

statEnv |-  TypeName derives from BaseTypeName

statEnv |-  attribute AttributeName of type TypeName { SimpleValue } matches AttributeType

A type can also be a sequence of items, in that case the matching rules also need to check whether the constraints described by the type as a regular expression hold. This is specified by the following rules.

The empty sequence matches the empty sequence type.

statEnv |-  () matches empty

If two values match two types, then their sequence matches the corresponding sequence type.

statEnv |-  Value₁ matches Type₁

statEnv |-  Value₂ matches Type₂

statEnv |-  Value₁,Value₂ matches Type₁,Type₂

If a value matches a type, then it also matches a choice type where that type is one of the choices.

statEnv |-  Value matches Type₁

statEnv |-  Value matches Type₁|Type₂

statEnv |-  Value matches Type₂

statEnv |-  Value matches Type₁|Type₂

If two values match two types, then their interleaving matches the corresponding all group.

statEnv |-  Value₁ matches Type₁

statEnv |-  Value₂ matches Type₂

statEnv |-  Value₁ interleave Value₂ yields Value

statEnv |-  Value matches Type₁ & Type₂

An optional type matches a value of that type or the empty sequence.

statEnv |-  Value matches (Type | empty)

statEnv |-  Value matches Type?

The following rules are used to match a value against a sequence of zero (or one) or more types.

statEnv |-  () matches Type*

statEnv |-  Value₁ matches Type      statEnv |-  Value₂ matches Type*

statEnv |-  Value₁, Value₂ matches Type*

statEnv |-  Value₁ matches Type      statEnv |-  Value₂ matches Type*

statEnv |-  Value₁, Value₂ matches Type+

Note

The above definition of type matching, although complete and precise, does not give a simple means to compute type matching. Notably, some of the above rules can be non-deterministic (e.g., the rule for matching of choice or repetition).

The structural component of the [XPath/XQuery] type system can be modeled by regular expressions. Regular expressions can be implemented by means of finite state automata. Computing type matching then is equivalent to check if a given sequence of items is recognized by its corresponding finite state automata. Finite state automata and their relationships to regular expressions have been extensively studied and documented in computer-science literature. The interested reader can consult the relevant literature, for instance [Languages], or [TATA].

8.3.2 Subtyping (<:)

Introduction

This section defines the semantics of subtyping in [XPath/XQuery]. Subtyping is used during static type analysis, in typeswitch, treat and assert expressions, and to check the correctness of function applications.

Note that intuitive relationships between types. For instance, that (Type,()) is equivalent to Type can be deduced using the subtyping judgment (and algorithm) described here.

Notation

The judgment

statEnv |-  Type₁ <: Type₂

holds if the first type is a subtype of the second.

Semantics

This judgment is true if and only if, for every value Value, if Value matches Type₁ holds, then Value matches Type₂ also holds.

Note

It is easy to see that the subtype relation <: is a partial order, i.e. it is reflexive:

statEnv  |-  Type <: Type     

and it is transitive: if,

statEnv  |-  Type₁ <: Type₂     

and,

statEnv  |-  Type₂ <: Type₃     

then,

statEnv  |-  Type₁ <: Type₃     

Finally, two types are equal if each is a subtype of the other, that is:

statEnv  |-  Type₁ <: Type₂     

and,

statEnv  |-  Type₂ <: Type₁     

then,

statEnv  |-  Type₁ = Type₂

Note

The above definition, although complete and precise, does not give a simple means to compute subtyping. Notably the definition above refers to values, which are not available at static type checking time.

The structural component of the [XPath/XQuery] type system can be modeled by regular expressions. Regular expressions can be implemented by means of finite state automata. Computing subtyping between two types can then be done by computing if inclusion holds between their corresponding finite state automata.

Finite state automata and how to compute operations on those automata, such as inclusion, emptiness or intersection, have been extensively studied and documented in the literature. The interested reader can consult the relevant literature on tree grammars, for instance [Languages], or [TATA].

8.4 Judgments for FLWOR and other expressions on sequences

Introduction

Some [XPath/XQuery] operations work on sequences of items. For instance, [For/FLWOR] expressions iterate over a sequence of items and the fn:unordered function can return all items in a sequence in any order, etc.

Static typing for those operations needs to infer a type acceptable for all the items in the sequence. This sometimes requires approximating the type known for each item individually.

Example

Assume the variable $shipTo is bound to the shipTo element

    <shipTo country="US">
        <name>Alice Smith</name>
        <street>123 Maple Street</street>
        <city>Mill Valley</city>
        <state>CA</state>
        <zip>90952</zip>
    </shipTo>

and has type

   element shipTo of type USAddress

The following query orders all children of the shipTo element by alphabetical order of their content.

   for $x in $shipTo/*
   order by $x/text()
   return $x

resulting in the sequence

    (<street>123 Maple Street</street>,
     <zip>90952</zip>,
     <name>Alice Smith</name>,
     <state>CA</state>,
     <city>Mill Valley</city>)

This operation iterates over the elements in the input sequence returned by the expression $shipTo/*, whose type is the content of a type USAddress.

    (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)

During static typing, one must give a type to the variable $x which corresponds to the type of each element in the sequence. Since each item is of a different type, one must find an item type which is valid for all cases in the sequence. This can be done by using a choice for the variable $x, as follows

    (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)

This type indicates that the type of the variable can be of any of the item types in the input sequence.

The static inference also needs to approximate the number of occurrences of items in the sequence. In this example, there is at least one item and more than one, so the closest occurrence indicator is + for one or more items.

The static inference for this example finally results in the following type.

    (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)+

[Definition: A Prime types is a choice of item types]. This section defines two functions on types that compute the prime type of an arbitrary type, and approximate the occurrence of items in an arbitrary type. These type functions are used in the static semantics of many expressions, including "for", "some", and "every" expressions, and many functions, including "fn:unordered" and "fn:distinct".

Notation

A choice of item types is called a prime type, as described by the following grammar production.

Prime Types

[44 (Formal)]   
PrimeType
   ::=   
FormalItemType
| (PrimeType "|" PrimeType)

Notation

The type function prime(Type) extracts all item types from the type Type, and combines them into a choice.

The function quantifier(Type) approximates the possible number of items in Type with the occurrence indicators supported by the [XPath/XQuery] type system (?, +, *).

For interim results, the auxiliary occurrence indicator 1 denotes exactly one occurrence.

Semantics

The prime function is defined by induction as follows.

prime(FormalItemType) |   =   | FormalItemType
prime(empty) |   =   | none
prime(none) |   =   | none
prime(Type₁ , Type₂) |   =   | prime(Type₁) | prime(Type₂)
prime(Type₁ & Type₂) |   =   | prime(Type₁) | prime(Type₂)
prime(Type₁ | Type₂) |   =   | prime(Type₁) | prime(Type₂)
prime(Type?) |   =   | prime(Type)
prime(Type*) |   =   | prime(Type)
prime(Type+) |   =   | prime(Type)

Semantics

The quantifier function is defined by induction as follows.

quantifier(FormalItemType) |   =   | 1
quantifier(empty) |   =   | ?
quantifier(none) |   =   | 1
quantifier(Type₁ , Type₂) |   =   | quantifier(Type₁) , quantifier(Type₂)
quantifier(Type₁ & Type₂) |   =   | quantifier(Type₁) , quantifier(Type₂)
quantifier(Type₁ | Type₂) |   =   | quantifier(Type₁) | quantifier(Type₂)
quantifier(Type?) |   =   | quantifier(Type) · ?
quantifier(Type*) |   =   | quantifier(Type) · *
quantifier(Type+) |   =   | quantifier(Type) · +

This definition uses the sum (OccurrenceIndicator₁ , OccurrenceIndicator₂), the choice (OccurrenceIndicator₁ | OccurrenceIndicator₂), and the product (OccurrenceIndicator₁ · OccurrenceIndicator₂) of two occurrence indicators OccurrenceIndicator₁, OccurrenceIndicator₂, which are defined by the following tables.

 , 
 1 
 ? 
 + 
 * 

 1 
 + 
 + 
 + 
 + 

 ? 
 + 
 * 
 + 
 * 

 + 
 + 
 + 
 + 
 + 

 * 
 + 
 * 
 + 
 * 

 | 
 1 
 ? 
 + 
 * 

 1 
 1 
 ? 
 + 
 * 

 ? 
 ? 
 ? 
 * 
 * 

 + 
 + 
 * 
 + 
 * 

 * 
 * 
 * 
 * 
 * 

 · 
 1 
 ? 
 + 
 * 

 1 
 1 
 ? 
 + 
 * 

 ? 
 ? 
 ? 
 * 
 * 

 + 
 + 
 * 
 + 
 * 

 * 
 * 
 * 
 * 
 * 

Examples

For example, here are the result of applying prime and quantifier on a few simple types.

  prime(element a+)                         = element a
  prime(element a | empty)                  = element a
  prime(element a?,element b?)              = element a | element b
  prime(element a | element b+, element c*) = element a | element b | element c

  quantifier(element a+)                         = +
  quantifier(element a | empty)                  = ?
  quantifier(element a?,element b?)              = *
  quantifier(element a | element b+, element d*) = +

Note that the last occurrence indicator should be '+', since the regular expression is such that there must be at least one element in the sequence (this element being an 'a' element or a 'b' element).

Note

Note that prime(Type) · quantifier(Type) is always a super type of the original type Type I.e., prime(Type) · quantifier(Type) <: Type always holds. Therefore, it is appropriate to used it as an approximation for the type of an expression. This property is required for the soundness of the static type analysis.

Semantics

Finally, a type Type and an occurrence indicator can be combined back together to yield a new type with the · operation, as follows.

Type · 1 |   =   | Type
Type · ? |   =   | Type?
Type · + |   =   | Type+
Type · * |   =   | Type*

8.5 Judgments for function calls

Introduction

Function calls can perform type promotion between atomic types. This section introduces judgments which describe type promotion for the purpose of the dynamic and static semantics. These promotion rules include promoting xs:untypedAtomic to any other type.

8.5.1 Type promotion

Notation

The judgment

statEnv |-  Type₁ can be promoted to Type₂

holds if type Type₁ can be promoted to type Type₂.

Example

For example, the following judgments hold:

  xs:integer  can be promoted to  xs:integer
  xs:decimal  can be promoted to  xs:float
  xs:integer  can be promoted to  xs:float
  xs:float    can be promoted to  xs:double

Semantics

This judgment is specified by the following rules.

xs:decimal can be promoted to xs:float:

statEnv |-  xs:decimal can be promoted to xs:float

xs:float can be promoted to xs:double:

statEnv |-  xs:float can be promoted to xs:double

xs:untypedAtomic can be promoted to any atomic type:

statEnv |-  Type <: xs:anyAtomicType

statEnv |-  xs:untypedAtomic can be promoted to Type

A type can be promoted to itself or to any type of which it is a subtype:

statEnv |-  Type can be promoted to Type

statEnv  |-  Type <: Type₁

statEnv |-  Type can be promoted to Type₁

Type promotion is transitive:

statEnv |-  Type₁ can be promoted to Type₂      statEnv |-  Type₂ can be promoted to Type₃

statEnv |-  Type₁ can be promoted to Type₃

Finally, type promotion distributes over occurrence and union constructors.

statEnv |-  prime(Type₁) can be promoted to prime(Type₂)      quantifier(Type₁) <= quantifier(Type₂)

statEnv |-  Type₁ can be promoted to Type₂

statEnv |-  Type₁ can be promoted to Type      statEnv |-  Type₂ can be promoted to Type

statEnv |-  (Type₁ | Type₂) can be promoted to Type

where the "<=" operator for occurrence indicators denotes set inclusion of the subsets of the allowed occurrences.

Notation

The judgment

statEnv |-  Value₁ against Type₂ promotes to Value₂

holds if value Value₁ can be promoted to the value Value₂ against the type Type₂.

Example

For example, the following judgments hold

  1     of type xs:integer  against  xs:integer  promotes to  1     of type xs:integer
  1     of type xs:integer  against  xs:decimal  promotes to  1     of type xs:integer
  1     of type xs:integer  against  xs:float    promotes to  1.0e0 of type xs:float
  1.0e0 of type xs:float    against  xs:double   promotes to  1.0e0 of type xs:double

Note that type promotion changes the value, and only occurs if the input value does not match the target type.

Semantics

This judgment is specified by the following rules.

If the value matches the target type, then it is promoted to itself

statEnv |-  Value matches Type

statEnv |-  Value against Type promotes to Value

If the value does not match the target type, but is an atomic value and it matches a type which can be promoted to the target type, then the value is cast to the target type.

statEnv |-  AtomicValue₁ matches AtomicType₁

statEnv |-  AtomicType₁ can be promoted to AtomicType₂

AtomicType₁ != AtomicType₂

AtomicValue₁ cast value to type AtomicType₂ => AtomicValue₂

statEnv |-  AtomicValue₁ against AtomicType₂ promotes to AtomicValue₂

8.6 Judgments for validation modes and contexts

8.6.1 Elements in validation mode

Notation

A validation mode may occur explicitly in a validate expression [4.13 Validate Expressions]. The following with mode judgment resolves an element name within a given validation mode to the type that the element name denotes. The judgment is used in the semantics of the validate expression and in sequence type.

The judgment

statEnv |-  ElementNameOrWildcard with mode ValidationMode resolves to Type

holds when the possibly optional element name resolves to the given type in the given validation mode.

Semantics

We start with the rules for the global validation context.

If no element name is present, the global validation context resolves to the union of all element types that are globally declared.

statEnv |-  ElementName₁ of elem/type expands to expanded-QName₁

...

statEnv |-  ElementNamen of elem/type expands to expanded-QNamen

statEnv.elemDecl(expanded-QName₁) = define element ElementName₁ OptSubstitution 1 OptNillable₁ TypeReference₁

...

statEnv.elemDecl(expanded-QNamen) = define element ElementNamen OptSubstitution n OptNillablen TypeReferencen

statEnv |-  with mode ValidationMode resolves to (element ElementName₁ | ... | element ElementNamen)

If the element name is globally declared in the schema, it resolves to the element type of the corresponding global element declaration, independently of the validation mode.

statEnv |-  ElementName of elem/type expands to expanded-QName

statEnv.elemDecl(expanded-QName) = define element ElementName OptSubstitution OptNillable TypeReference

statEnv |-  ElementName with mode ValidationMode resolves to element ElementName

If an element name is not globally defined and the validation mode is lax, then the element name resolves to the element type with the given element name with any content type.

statEnv |-  ElementName of elem/type expands to expanded-QName

statEnv.elemDecl(expanded-QName) undefined

statEnv |-  ElementName with mode lax resolves to element ElementName of type xs:anyType

A Normalized core and formal grammars

This section contains the set of productions for the of [XPath/XQuery] grammar after it has been normalized, sometimes referred to as the "core" grammar, and for the formal grammar productions.

A.1 Core BNF

The following grammar uses the same Basic EBNF notation as [XML], except that grammar symbols always have initial capital letters. The EBNF contains the lexemes embedded in the productions.

Named Terminals

[98]    | IntegerLiteral |    ::=    | Digits
[99]    | DecimalLiteral |    ::=    | ("." Digits) | (Digits "." [0-9]*)
[100]    | DoubleLiteral |    ::=    | (("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits
[101]    | StringLiteral |    ::=    | ('"' (EscapeQuot | [^"])* '"') | ("'" (EscapeApos | [^'])* "'")
[102]    | EscapeQuot |    ::=    | '""'
[103]    | EscapeApos |    ::=    | "''"
[104]    | ElementContentChar |    ::=    | Char - [{}<&]
[105]    | QuotAttrContentChar |    ::=    | Char - ["{}<&]
[106]    | AposAttrContentChar |    ::=    | Char - ['{}<&]
[107]    | PITarget |    ::=    | [http://www.w3.org/TR/REC-xml#NT-PITarget] XML
[108]    | QName |    ::=    | [http://www.w3.org/TR/REC-xml-names/#NT-QName] Names
[109]    | NCName |    ::=    | [http://www.w3.org/TR/REC-xml-names/#NT-NCName] Names
[110]    | S |    ::=    | [http://www.w3.org/TR/REC-xml#NT-S] XML
[111]    | Char |    ::=    | [http://www.w3.org/TR/REC-xml#NT-Char] XML

Non-Terminals

[1]   
ModuleDecl
   ::=   
"module" "namespace" NCName "=" URILiteral Separator

[2]   
Separator
   ::=   
";"

[3]   
NamespaceDecl
   ::=   
"declare" "namespace" NCName "=" URILiteral

[4]   
DefaultNamespaceDecl
   ::=   
"declare" "default" ("element" | "function") "namespace" URILiteral

[5]   
OptionDecl
   ::=   
"declare" "option" QName StringLiteral

[6]   
OrderingModeDecl
   ::=   
"declare" "ordering" ("ordered" | "unordered")

[7]   
EmptyOrderDecl
   ::=   
"declare" "default" "order" "empty" ("greatest" | "least")

[8]   
CopyNamespacesDecl
   ::=   
"declare" "copy-namespaces" PreserveMode "," InheritMode

[9]   
PreserveMode
   ::=   
"preserve" | "no-preserve"

[10]   
InheritMode
   ::=   
"inherit" | "no-inherit"

[11]   
DefaultCollationDecl
   ::=   
"declare" "default" "collation" URILiteral

[12]   
BaseURIDecl
   ::=   
"declare" "base-uri" URILiteral

[13]   
SchemaImport
   ::=   
"import" "schema" SchemaPrefix? URILiteral ("at" URILiteral ("," URILiteral)*)?

[14]   
SchemaPrefix
   ::=   
("namespace" NCName "=") | ("default" "element" "namespace")

[15]   
ModuleImport
   ::=   
"import" "module" ("namespace" NCName "=")? URILiteral ("at" URILiteral ("," URILiteral)*)?

[16]   
VarDecl
   ::=   
"declare" "variable" "$" QName TypeDeclaration? ((":=" ExprSingle) | "external")

[17]   
ConstructionDecl
   ::=   
"declare" "construction" ("strip" | "preserve")

[18]   
FunctionDecl
   ::=   
"declare" "function" QName "(" ParamList? ")" ("as" SequenceType)? (EnclosedExpr | "external")

[19]   
ParamList
   ::=   
Param ("," Param)*

[20]   
Param
   ::=   
"$" QName TypeDeclaration?

[21]   
EnclosedExpr
   ::=   
"{" Expr "}"

[22]   
Expr
   ::=   
ExprSingle ("," ExprSingle)*

[23]   
ExprSingle
   ::=   
FLWORExpr
| QuantifiedExpr
| TypeswitchExpr
| IfExpr
| OrExpr

[24]   
FLWORExpr
   ::=   
(ForClause | LetClause) "return" ExprSingle

[25]   
ForClause
   ::=   
"for" "$" VarName TypeDeclaration? PositionalVar? "in" ExprSingle

[26]   
PositionalVar
   ::=   
"at" "$" VarName

[27]   
LetClause
   ::=   
"let" "$" VarName TypeDeclaration? ":=" ExprSingle

[28]   
OrderByClause
   ::=   
(("order" "by") | ("stable" "order" "by")) OrderSpecList

[29]   
OrderSpecList
   ::=   
OrderSpec ("," OrderSpec)*

[30]   
OrderSpec
   ::=   
ExprSingle OrderModifier

[31]   
OrderModifier
   ::=   
("ascending" | "descending")? ("empty" ("greatest" | "least"))? ("collation" URILiteral)?

[32]   
QuantifiedExpr
   ::=   
("some" | "every") "$" VarName TypeDeclaration? "in" ExprSingle ("," "$" VarName TypeDeclaration? "in" ExprSingle)* "satisfies" ExprSingle

[33]   
TypeswitchExpr
   ::=   
"typeswitch" "(" Expr ")" CaseClause+ "default" "$" VarName "return" ExprSingle

[34]   
CaseClause
   ::=   
"case" "$" VarName "as" SequenceType "return" ExprSingle

[35]   
IfExpr
   ::=   
"if" "(" Expr ")" "then" ExprSingle "else" ExprSingle

[36]   
OrExpr
   ::=   
AndExpr ( "or" AndExpr )*

[37]   
AndExpr
   ::=   
CastableExpr ( "and" CastableExpr )*

[38]   
CastableExpr
   ::=   
CastExpr ( "castable" "as" SingleType )?

[39]   
CastExpr
   ::=   
ValueExpr ( "cast" "as" SingleType )?

[40]   
ValueExpr
   ::=   
ValidateExpr | StepExpr | ExtensionExpr

[41]   
ValidateExpr
   ::=   
"validate" ValidationMode? "{" Expr "}"

[42]   
ValidationMode
   ::=   
"lax" | "strict"

[43]   
ExtensionExpr
   ::=   
Pragma+ "{" Expr? "}"

[44]   
Pragma
   ::=   
"(#" S? QName (S PragmaContents)? "#)"

[45]   
PragmaContents
   ::=   
(Char* - (Char* '#)' Char*))

[46]   
StepExpr
   ::=   
PrimaryExpr | AxisStep

[47]   
AxisStep
   ::=   
ReverseStep | ForwardStep

[48]   
ForwardStep
   ::=   
ForwardAxis NodeTest

[49]   
ForwardAxis
   ::=   
("child" "::")
| ("descendant" "::")
| ("attribute" "::")
| ("self" "::")
| ("descendant-or-self" "::")
| ("namespace" "::")

[50]   
ReverseStep
   ::=   
ReverseAxis NodeTest

[51]   
ReverseAxis
   ::=   
("parent" "::")
| ("ancestor" "::")
| ("ancestor-or-self" "::")

[52]   
NodeTest
   ::=   
KindTest | NameTest

[53]   
NameTest
   ::=   
QName | Wildcard

[54]   
Wildcard
   ::=   
"*"
| (NCName ":" "*")
| ("*" ":" NCName)

[55]   
PrimaryExpr
   ::=   
Literal | VarRef | ParenthesizedExpr | FunctionCall | OrderedExpr | UnorderedExpr | Constructor

[56]   
Literal
   ::=   
NumericLiteral | StringLiteral

[57]   
NumericLiteral
   ::=   
IntegerLiteral | DecimalLiteral | DoubleLiteral

[58]   
VarRef
   ::=   
"$" VarName

[59]   
VarName
   ::=   
QName

[60]   
ParenthesizedExpr
   ::=   
"(" Expr? ")"

[61]   
OrderedExpr
   ::=   
"ordered" "{" Expr "}"

[62]   
UnorderedExpr
   ::=   
"unordered" "{" Expr "}"

[63]   
FunctionCall
   ::=   
QName "(" (ExprSingle ("," ExprSingle)*)? ")"

[64]   
Constructor
   ::=   
ComputedConstructor

[65]   
ComputedConstructor
   ::=   
CompDocConstructor
| CompElemConstructor
| CompAttrConstructor
| CompTextConstructor
| CompCommentConstructor
| CompPIConstructor

[66]   
CompDocConstructor
   ::=   
"document" "{" Expr "}"

[67]   
CompElemConstructor
   ::=   
"element" (QName | ("{" Expr "}")) "{" ContentExpr "}" "{" NamespaceBinding* "}"

[68]   
NamespaceBinding
   ::=   
"namespace" NCName "{" URILiteral "}"

[69]   
ContentExpr
   ::=   
Expr

[70]   
CompAttrConstructor
   ::=   
"attribute" (QName | ("{" Expr "}")) "{" Expr "}"

[71]   
CompTextConstructor
   ::=   
"text" "{" Expr "}"

[72]   
CompCommentConstructor
   ::=   
"comment" "{" Expr "}"

[73]   
CompPIConstructor
   ::=   
"processing-instruction" (NCName | ("{" Expr "}")) "{" Expr? "}"

[74]   
SingleType
   ::=   
AtomicType "?"?

[75]   
TypeDeclaration
   ::=   
"as" SequenceType

[76]   
SequenceType
   ::=   
("empty-sequence" "(" ")")
| (ItemType OccurrenceIndicator?)

[77]   
OccurrenceIndicator
   ::=   
"?" | "*" | "+"

[78]   
ItemType
   ::=   
KindTest | ("item" "(" ")") | AtomicType

[79]   
AtomicType
   ::=   
QName

[80]   
KindTest
   ::=   
DocumentTest
| ElementTest
| AttributeTest
| SchemaElementTest
| SchemaAttributeTest
| PITest
| CommentTest
| TextTest
| AnyKindTest

[81]   
AnyKindTest
   ::=   
"node" "(" ")"

[82]   
DocumentTest
   ::=   
"document-node" "(" (ElementTest | SchemaElementTest)? ")"

[83]   
TextTest
   ::=   
"text" "(" ")"

[84]   
CommentTest
   ::=   
"comment" "(" ")"

[85]   
PITest
   ::=   
"processing-instruction" "(" (NCName | StringLiteral)? ")"

[86]   
AttributeTest
   ::=   
"attribute" "(" (AttribNameOrWildcard ("," TypeName)?)? ")"

[87]   
AttribNameOrWildcard
   ::=   
AttributeName | "*"

[88]   
SchemaAttributeTest
   ::=   
"schema-attribute" "(" AttributeDeclaration ")"

[89]   
AttributeDeclaration
   ::=   
AttributeName

[90]   
ElementTest
   ::=   
"element" "(" (ElementNameOrWildcard ("," TypeName "?"?)?)? ")"

[91]   
ElementNameOrWildcard
   ::=   
ElementName | "*"

[92]   
SchemaElementTest
   ::=   
"schema-element" "(" ElementDeclaration ")"

[93]   
ElementDeclaration
   ::=   
ElementName

[94]   
AttributeName
   ::=   
QName

[95]   
ElementName
   ::=   
QName

[96]   
TypeName
   ::=   
QName

[97]   
URILiteral
   ::=   
StringLiteral

[112]   
Digits
   ::=   
[0-9]+

A.2 Formal BNF

The following grammar uses the same Basic EBNF notation as [XML], except that grammar symbols always have initial capital letters. The EBNF contains the lexemes embedded in the productions.

Named Terminals

[91]    | HexDigits |    ::=    | [0-9a-fA-F]+
[92]    | CharRef |    ::=    | "&#" (Digits | ("x" HexDigits)) ";"
[93]    | Char |    ::=    | #x0009#x000D#x000A#x0020-#xFFFD

Non-Terminals

[1]   
AtomicValueContent
   ::=   
String
| Boolean
| Decimal
| Float
| Double
| Duration
| DateTime
| Time
| Date
| GYearMonth
| GYear
| GMonthDay
| GDay
| GMonth
| HexBinary
| Base64Binary
| AnyURI
| expanded-QName
| NOTATION

[2]   
TypeAnnotation
   ::=   
"of" "type" TypeName

[3]   
ElementName
   ::=   
QName

[4]   
ElementNameOrWildcard
   ::=   
QName | "*"

[5]   
AttributeNameOrWildcard
   ::=   
QName | "*"

[6]   
AttributeName
   ::=   
QName

[7]   
Value
   ::=   
Item
| (Value "," Value)
| ("(" ")")

[8]   
SimpleValue
   ::=   
AtomicValue
| (SimpleValue "," SimpleValue)
| ("(" ")")

[9]   
ElementValue
   ::=   
"element" ElementName "nilled"? TypeAnnotation? "{" Value "}" ("{" NamespaceBindings "}")?

[10]   
AttributeValue
   ::=   
"attribute" AttributeName TypeAnnotation? "{" SimpleValue "}"

[11]   
DocumentValue
   ::=   
"document" "{" Value "}"

[12]   
TextValue
   ::=   
"text" "{" String "}"

[13]   
CommentValue
   ::=   
"comment" "{" String "}"

[14]   
ProcessingInstructionValue
   ::=   
"processing-instruction" NCName "{" String "}"

[15]   
NamespaceBindings
   ::=   
NamespaceBinding ("," NamespaceBinding)*

[16]   
LocationHints
   ::=   
"at" URILiteral ("," URILiteral)*

[17]   
NamespaceBinding
   ::=   
"namespace" NCName "{" AnyURI "}"

[18]   
Prefix
   ::=   
NCName

[19]   
LocalPart
   ::=   
NCName

[20]   
NodeValue
   ::=   
ElementValue
| AttributeValue
| DocumentValue
| TextValue
| CommentValue
| ProcessingInstructionValue

[21]   
Item
   ::=   
NodeValue
| AtomicValue

[22]   
AtomicValue
   ::=   
AtomicValueContent TypeAnnotation?

[23]   
TypeName
   ::=   
QName

[24]   
Type
   ::=   
FormalItemType
| (Type OccurrenceIndicator)
| (Type "&" Type)
| (Type "," Type)
| (Type "|" Type)
| "empty"
| "none"
| ("(" Type ")")

[25]   
FormalItemType
   ::=   
AtomicTypeName | NodeType

[26]   
NodeType
   ::=   
DocumentType
| AttributeType
| ElementContentType

[27]   
ElementContentType
   ::=   
ElementType
| "comment"
| "processing-instruction"
| "text"

[28]   
AtomicTypeName
   ::=   
TypeName

[29]   
ElementType
   ::=   
"element" ElementNameOrWildcard OptTypeSpecifier

[30]   
TypeSpecifier
   ::=   
OptNillable TypeReference

[31]   
AttributeType
   ::=   
"attribute" AttributeNameOrWildcard OptTypeReference

[32]   
Nillable
   ::=   
"nillable"

[33]   
TypeDerivation
   ::=   
ComplexTypeDerivation | AtomicTypeDerivation

[34]   
ComplexTypeDerivation
   ::=   
Derivation? OptMixed "{" Type? "}"

[35]   
AtomicTypeDerivation
   ::=   
"restricts" AtomicTypeName

[36]   
TypeReference
   ::=   
"of" "type" TypeName

[37]   
Derivation
   ::=   
("restricts" TypeName)
| ("extends" TypeName)

[38]   
Mixed
   ::=   
"mixed"

[39]   
Definition
   ::=   
("define" "element" ElementName OptSubstitution OptNillable TypeReference)
| ("define" "attribute" AttributeName TypeReference)
| ("define" "type" TypeName TypeDerivation)

[40]   
Definitions
   ::=   
(Definition Definitions)?

[41]   
Substitution
   ::=   
"substitutes" "for" ElementName

[42]   
AttributeModel
   ::=   
AttributeType
| (AttributeType "?")
| (AttributeModel "&" AttributeModel)
| ("(" ")")

[43]   
ElementModel
   ::=   
ElementType
| (ElementType "?")
| (ElementModel "&" ElementModel)
| ("(" ")")
| "none"

[44]   
PrimeType
   ::=   
FormalItemType
| (PrimeType "|" PrimeType)

[45]   
DocumentType
   ::=   
"document" ("{" Type "}")?

[46]   
SPragma
   ::=   
("include" | "import" | "redefine" | "annotation")*

[47]   
Content
   ::=   
(("simpleType" | "complexType" | "element" | "attribute" | "attributeGroup" | "group" | "notation") "annotation"*)*

[48]   
MixedAttribute
   ::=   
"mixed" "=" Boolean

[49]   
NillableAttribute
   ::=   
"nillable" "=" Boolean

[50]   
substitutionGroupAttribute
   ::=   
"substitutionGroup" "=" QName

[51]   
maxLength
   ::=   
"maxLength" "=" "nonNegativeInteger"

[52]   
minLength
   ::=   
"minLength" "=" "nonNegativeInteger"

[53]   
length
   ::=   
"length" "=" "nonNegativeInteger"

[54]   
maxOccurs
   ::=   
"maxOccurs" "=" ("nonNegativeInteger" | "unbounded")

[55]   
minOccurs
   ::=   
"minOccurs" "=" "nonNegativeInteger"

[56]   
OccursAttributes
   ::=   
maxOccurs | minOccurs | maxLength | minLength | length

[57]   
ComplexTypeContent
   ::=   
"annotation"? ("simpleContent" | "complexContent" | (ChildrenContent AttributeContent))

[58]   
ChildrenContent
   ::=   
("group" | "all" | "choice" | "sequence")?

[59]   
GroupComponent
   ::=   
"element" | "group" | "choice" | "sequence" | "any"

[60]   
AttributeContent
   ::=   
("attribute" | "attributeGroup")* "anyAttribute"?

[61]   
UseAttribute
   ::=   
"use" "=" ("optional" | "prohibited" | "required")

[62]   
DefaultAttribute
   ::=   
"default" "=" String

[63]   
FixedAttribute
   ::=   
"fixed" "=" String

[64]   
PrincipalNodeKind
   ::=   
"element" | "attribute" | "namespace"

[65]   
FormalFLWORClause
   ::=   
ForClause | LetClause | WhereClause | OrderByClause

[66]   
FormalReturnClause
   ::=   
FormalFLWORExpr | ("return" Expr)

[67]   
FormalFLWORExpr
   ::=   
FormalFLWORClause FormalReturnClause

[68]   
FormalCaseClauses
   ::=   
(FormalCaseClause FormalCaseClauses) | FormalDefaultCaseClause

[69]   
FormalCaseClause
   ::=   
"case" "$" VarName "as" SequenceType "return" Expr

[70]   
FormalDefaultCaseClause
   ::=   
"default" "$" VarName "return" Expr

[71]   
PrologDeclList
   ::=   
(PrologDecl Separator PrologDeclList)?

[72]   
PrologDecl
   ::=   
DefaultCollationDecl
| BaseURIDecl
| ConstructionDecl
| OrderingModeDecl
| EmptyOrderDecl
| CopyNamespacesDecl
| SchemaImport
| ModuleImport
| NamespaceDecl
| DefaultNamespaceDecl
| VarDecl
| FunctionDecl
| OptionDecl

[73]   
OptAtomicType
   ::=   
AtomicTypeName | (AtomicTypeName "?") | "empty"

[74]   
OptMixed
   ::=   
Mixed?

[75]   
OptNillable
   ::=   
Nillable?

[76]   
OptSubstitution
   ::=   
Substitution?

[77]   
OptTypeSpecifier
   ::=   
TypeSpecifier?

[78]   
OptTypeReference
   ::=   
TypeReference?

[79]   
OptTypeDeclaration
   ::=   
TypeDeclaration?

[80]   
OptPositionalVar
   ::=   
PositionalVar?

[81]   
OptVarName
   ::=   
("$" VarName)?

[82]   
OptLocationHints
   ::=   
LocationHints?

[83]   
ElementContentUnit
   ::=   
DirectConstructor | EnclosedExpr | DirCharsUnit

[84]   
DirCharsUnit
   ::=   
(CDataSection | PredefinedEntityRef | CharRef | "{{" | "}}" | ElementContentChar)+

[85]   
FunctionSig
   ::=   
"declare" "function" expanded-QName "(" TypeList? ")" "as" SequenceType

[86]   
TypeList
   ::=   
SequenceType ("," Type)*

[87]   
AttributeContentUnits
   ::=   
AttributeContentUnit*

[88]   
AttributeContentUnit
   ::=   
EscapeQuot | QuotAttrValueContent

[89]   
ConstructionMode
   ::=   
"preserve" | "strip"

[90]   
Axis
   ::=   
ForwardAxis | ReverseAxis

B Index of judgments

Here is the list of the judgments defined in this specification.

Main judgments:

statEnv |-  Expr : Type

statEnv |-  Expr :ext Type

statEnv; dynEnv |-  Expr => Value

Auxiliary judgments:

statEnv |-  Type₁ <: Type₂

statEnv |-  (AnyURI | #MAIN) =>module_statEnv statEnv

statEnv |-  (AnyURI | #MAIN) =>module_dynEnv dynEnv

statEnv₁ |-  PrologDeclList =>stat statEnv₂ with PrologDeclList₁

dynEnv₁ |-  PrologDeclList =>dyn dynEnv₂

statEnv₁ |-  Definitions =>type statEnv₂

dynEnv₁ ; AnyURI |-  (expanded-QName₁(Type1,1, ..., Type1,n)), ···, (expanded-QNamek(Typek,1, ..., Typek,n)) =>import_functions dynEnv₂

dynEnv₁ ; AnyURI |-  (expanded-QName₁, Type₁), ···, (expanded-QNamen, Typen) =>import_variables dynEnv₂

statEnv |-  OptMixed Type₁ adjusts to Type₂

statEnv |-  Value₁ against Type₂ promotes to Value₂

dynEnv |-  Value₁ against FormalCaseClauses => Value₂

statEnv |-  annotate as Type ( Value₁ ) => Value₂

statEnv |-  axis Axis of Type₁ : Type₂

dynEnv |-  axis Axis of Value₁ => Value₂

statEnv |-  Type₁ case FormalCaseClause : Type

statEnv |-  Type₁ can be promoted to Type₂

AtomicValue₁ cast value to type AtomicType => AtomicValue₂

statEnv |-  data on Type₁ : Type₂

statEnv |-  Value₁ erases to Value₂

statEnv |-  TypeSpecifier expands to Type

statEnv |-  Type₁ extended by Type₂ is Type

dynEnv₁ extended with dynamic environment dynEnv₂ yields dynEnv₃ for uri AnyURI

statEnv₁ extended with static environment statEnv₂ yields statEnv₃ for uri AnyURI

Value filter @QName => absent

statEnv |-  function declaration FunctionDecl with signature FunctionSig : Typer

dynEnv |-  function expanded-QName with types (Type₁,...,Typen) on values (Value₁,...,Valuen) yields Value

dynEnv |-  LiteralExpr has atomic value AtomicValue

statEnv |-  Type₁ has attribute content Type₂

statEnv |-  Type₁ has node content Type₂

Axis has principal PrincipalNodeKind

statEnv |-  Value₁ interleave Value₂ yields Value₃

statEnv |-  Type₂ is Type₁ extended with union interpretation of TypeName

AnyURI is target namespace of modules Module₁ ... Modulen

statEnv |-  Value matches Type

statEnv |-  Type₁ mixes to Type₂

statEnv |-  ElementName name lookup ElementType yields OptNillable TypeReference

statEnv |-  AttributeName name lookup AttributeType yields TypeReference

statEnv |-  nil-annotate as Nillable? Type ( Value₁ ) => Value₂

statEnv |-  QName of attr expands to expanded-QName

statEnv |-  QName of elem/type expands to expanded-QName

statEnv |-  QName of func expands to expanded-QName

statEnv |-  QName of var expands to Variable

expanded-QName operator type for AtomicType₁ and AtomicType₂ is AtomicType₃

statEnv |-  TypeReference resolves to TypeName { Type }

statEnv |-  simply annotate as SimpleType ( SimpleValue ) => SimpleValue₂

statEnv |-  SimpleValue simply erases to String

statEnv |-  ElementName₁ substitutes for ElementName₂

statEnv |-  AttributeType type lookup TypeReference

statEnv |-  ElementType type lookup OptNillable TypeReference

statEnv |-  test NodeTest with PrincipalNodeKind of Type₁ : Type₂

dynEnv |-  test NodeTest with PrincipalNodeKind of Value₁ => Value₂

statEnv |-  ElementNameOrWildcard with mode ValidationMode resolves to Type

C Functions and Operators

C.1 Functions and Operators used in the Formal Semantics

Here is the list of functions from the [Functions and Operators] document that are used in the [XPath/XQuery] Formal Semantics:

Section 10.6.6 op:add-dayTimeDurationsFO

Section 10.8.5 op:add-dayTimeDuration-to-dateTimeFO

Section 10.8.9 op:add-dayTimeDuration-to-dateFO

Section 10.8.12 op:add-dayTimeDuration-to-timeFO

Section 10.6.1 op:add-yearMonthDurationsFO

Section 10.8.4 op:add-yearMonthDuration-to-dateTimeFO

Section 10.8.8 op:add-yearMonthDuration-to-dateFO

Section 9.2.1 op:boolean-equalFO

Section 9.2.3 op:boolean-greater-thanFO

Section 9.2.2 op:boolean-less-thanFO

Section 15.1.1 fn:booleanFO

Section 7.3.2 fn:compareFO

Section 15.1.2 op:concatenateFO

Section 15.4.1 fn:countFO

Section 10.4.6 op:dateTime-equalFO

Section 10.4.8 op:dateTime-greater-thanFO

Section 10.4.7 op:dateTime-less-thanFO

Section 10.4.4 op:dayTimeDuration-greater-thanFO

Section 10.4.3 op:dayTimeDuration-less-thanFO

Section 10.6.9 op:divide-dayTimeDurationFO

Section 10.6.4 op:divide-yearMonthDurationFO

Section 2.4 fn:dataFO

Section 15.1.4 fn:emptyFO

Section 3 The Error FunctionFO

Section 15.3.4 op:exceptFO

Section 9.1.2 fn:falseFO

Section 15.3.3 op:intersectFO

Section 14.6 op:is-same-nodeFO

Section 16.2 fn:lastFO

Section 10.6.8 op:multiply-dayTimeDurationFO

Section 10.6.3 op:multiply-yearMonthDurationFO

Section 14.8 op:node-afterFO

Section 14.7 op:node-beforeFO

Section 13.1.1 op:NOTATION-equalFO

Section 9.3.1 fn:notFO

Section 6.2.1 op:numeric-addFO

Section 6.2.4 op:numeric-divideFO

Section 6.3.1 op:numeric-equalFO

Section 6.3.3 op:numeric-greater-thanFO

Section 6.3.2 op:numeric-less-thanFO

Section 6.2.6 op:numeric-modFO

Section 6.2.3 op:numeric-multiplyFO

Section 6.2.2 op:numeric-subtractFO

Section 6.2.8 op:numeric-unary-minusFO

Section 6.2.7 op:numeric-unary-plusFO

Section 16.1 fn:positionFO

Section 11.2.1 op:QName-equalFO

Section 14.9 fn:rootFO

Section 6.4.4 fn:roundFO

Section 15.1.10 fn:subsequenceFO

Section 10.8.7 op:subtract-dayTimeDuration-from-dateTimeFO

Section 10.8.11 op:subtract-dayTimeDuration-from-dateFO

Section 10.8.13 op:subtract-dayTimeDuration-from-timeFO

Section 10.6.7 op:subtract-dayTimeDurationsFO

Section 10.8.6 op:subtract-yearMonthDuration-from-dateTimeFO

Section 10.8.10 op:subtract-yearMonthDuration-from-dateFO

Section 10.6.2 op:subtract-yearMonthDurationsFO

Section 15.5.1 op:toFO

Section 9.1.1 fn:trueFO

Section 15.3.2 op:unionFO

Section 10.4.2 op:yearMonthDuration-greater-thanFO

Section 10.4.1 op:yearMonthDuration-less-thanFO

C.2 Mapping of Overloaded Internal Functions

This section gives the semantics specific to overloaded internal functions (with prefix fs:) that are used to define overloaded XQuery operators (with prefix op:), such as comparison expressions or arithmetic expressions. Static typing for those functions are defined over unions of (possibly optional) atomic types. The semantics is obtained in three steps. First, a rule is applied to deal with the union of those (possibly optional) atomic types. A second set of rules treat the cases where one of the operands of those functions is the empty type (resp. empty sequence) or optional. Finally, a final rule deals with type promotion and access to an operators mapping table which maps the overloaded internal functions to the appropriate operator functions defined in [Functions and Operators] and give the corresponding type.

Notation

The following auxiliary grammar production describe optional atomic types.

OptAtomicType

[73 (Formal)]   
OptAtomicType
   ::=   
AtomicTypeName | (AtomicTypeName "?") | "empty"

Static Type Analysis

The following static typing rules apply generically to all the fs: special functions. They do not apply to any other function calls, which are treated in [4.1.5 Function Calls].

First, if the static type of one or several of the expressions passed as argument is a union of atomic types, the function call is type checked once separately for each atomic type in that union. The static type of the entire function call expression is then the union of the types computed in each case.

Type₁ = (OptAtomicType₁,1|...|OptAtomicTypem,1)

...

Typen = (OptAtomicType₁,n|...|OptAtomicTypem,n)

statEnv  |-  expanded-QName(OptAtomicType₁,1,..., OptAtomicType₁,n) : OptAtomicType₁'

...

statEnv  |-  expanded-QName(OptAtomicTypem,1,..., OptAtomicTypem,n) : OptAtomicTyper'

statEnv  |-  expanded-QName(Type₁, ..., Typen) : (OptAtomicType₁'|...|OptAtomicTyper')

Note

Note that this approach can be used since the type declared for a function parameter is never itself be a union.

The following rules deal with optional arguments. In the case of binary operators, if either one of the types of the operands is empty, the resulting type is empty.

Type₁ = empty

statEnv |-  expanded-QName(Type₁,Type₂) : empty

Type₂ = empty

statEnv |-  expanded-QName(Type₁,Type₂) : empty

If either one of the types of the operands is optional, the type obtained by propagating the optional occurrence indicator.

Type₁ = AtomicType₁

Type₂ = AtomicType₂?

statEnv |-  expanded-QName(AtomicType₁,AtomicType₂) : AtomicType₃

statEnv |-  expanded-QName(Type₁,Type₂) : AtomicType₃?

Type₁ = AtomicType₁?

Type₂ = AtomicType₂

statEnv |-  expanded-QName(AtomicType₁,AtomicType₂) : AtomicType₃

statEnv |-  expanded-QName(Type₁,Type₂) : AtomicType₃?

Type₁ = AtomicType₁?

Type₂ = AtomicType₂?

statEnv |-  expanded-QName(AtomicType₁,AtomicType₂) : AtomicType₃

statEnv |-  expanded-QName(Type₁,Type₂) : AtomicType₃?

In the case of unary operators, if the type of the operand is empty, the resulting type is empty.

Type₁ = empty

statEnv |-  expanded-QName(Type₁) : empty

Finally, the resulting type is obtained by performing type promotion and accessing the operators mapping table (using the operator type for judgment defined below).

statEnv  |-  AtomicType₁ can be promoted to AtomicType₁'

statEnv  |-  AtomicType₂ can be promoted to AtomicType₂'

expanded-QName operator type for AtomicType₁ and AtomicType₂ is AtomicType₃

statEnv  |-  expanded-QName(AtomicType₁,AtomicType₂) : AtomicType₃

statEnv  |-  AtomicType₁ can be promoted to AtomicType₁'

expanded-QName operator type for AtomicType₁ is AtomicType₃

statEnv  |-  expanded-QName(AtomicType₁) : AtomicType₃

Dynamic Evaluation

Each fs: overloaded operator maps to the corresponding equivalent overloaded op: operator, as defined in [Functions and Operators], and deals with the case where one of the operands is the empty sequence.

The dynamic semantics of the fs: operator is similar to using the following user-defined function.

declare function fs:opname($x1 as xs:anyAtomicType?, $x2 as xs:anyAtomicType?) as xs:anyAtomicType? {

  if (fn:empty($x1) or fn:empty($x2)) then () else [fs:opname($x1,$x2)]OverloadedOp

};

Where [fs:opname()]OverloadedOp maps to the corresponding op: operator in [Functions and Operators], as defined in the table below.

Notation

The operators mapping table is given below. The table is used to define the following auxiliary mapping rules and judgments.

The mapping rule for binary and unary operators

[fs:opname1(Expr₁,Expr₂)]OverloadedOp == op:opname2(Expr₁,Expr₂)

and

[fs:opname1(Expr₁)]OverloadedOp == op:opname2(Expr₁)

where the operator depends on the type of each value returned by Expr₁ and Expr₂.

The judgments for binary and unary operators

expanded-QName operator type for AtomicType₁ and AtomicType₂ is AtomicType₃

and

expanded-QName operator type for AtomicType₁ is AtomicType₃

hold when the operator table indicates that the operator expanded-QName has the output type AtomicType₃ for the input types AtomicType₁ and AtomicType₂.

Note that in the following table, all numeric functions are applied to operands with the same type. Values are promoted to compatible types using the function call semantics given in [4.1.5 Function Calls].

Gregorian refers to the types xs:gYearMonth, xs:gYear, xs:gMonthDay, xs:gDay, and xs:gMonth. For binary operators that accept two Gregorian-type operands, both operands must have the same type (for example, if one operand is of type xs:gDay, the other operand must be of type xs:gDay.)

Binary Operators

Internal Function | AtomicType₁ | AtomicType₂ | Denotes | AtomicType₃
fs:plus(A, B) | xs:integer | xs:integer | op:numeric-add(A, B) | xs:integer
fs:plus(A, B) | xs:decimal | xs:decimal | op:numeric-add(A, B) | xs:decimal
fs:plus(A, B) | xs:float | xs:float | op:numeric-add(A, B) | xs:float
fs:plus(A, B) | xs:double | xs:double | op:numeric-add(A, B) | xs:double
fs:plus(A, B) | xs:date | xs:yearMonthDuration | op:add-yearMonthDuration-to-date(A, B) | xs:date
fs:plus(A, B) | xs:yearMonthDuration | xs:date | op:add-yearMonthDuration-to-date(B, A) | xs:date
fs:plus(A, B) | xs:date | xs:dayTimeDuration | op:add-dayTimeDuration-to-date(A, B) | xs:date
fs:plus(A, B) | xs:dayTimeDuration | xs:date | op:add-dayTimeDuration-to-date(B, A) | xs:date
fs:plus(A, B) | xs:time | xs:dayTimeDuration | op:add-dayTimeDuration-to-time(A, B) | xs:time
fs:plus(A, B) | xs:dayTimeDuration | xs:time | op:add-dayTimeDuration-to-time(B, A) | xs:time
fs:plus(A, B) | xs:dateTime | xs:yearMonthDuration | op:add-yearMonthDuration-to-dateTime(A, B) | xs:dateTime
fs:plus(A, B) | xs:yearMonthDuration | xs:dateTime | op:add-yearMonthDuration-to-dateTime(B, A) | xs:dateTime
fs:plus(A, B) | xs:dateTime | xs:dayTimeDuration | op:add-dayTimeDuration-to-dateTime(A, B) | xs:dateTime
fs:plus(A, B) | xs:dayTimeDuration | xs:dateTime | op:add-dayTimeDuration-to-dateTime(B, A) | xs:dateTime
fs:plus(A, B) | xs:yearMonthDuration | xs:yearMonthDuration | op:add-yearMonthDurations(A, B) | xs:yearMonthDuration
fs:plus(A, B) | xs:dayTimeDuration | xs:dayTimeDuration | op:add-dayTimeDurations(A, B) | xs:dayTimeDuration
fs:minus(A, B) | xs:integer | xs:integer | op:numeric-subtract(A, B) | xs:integer
fs:minus(A, B) | xs:decimal | xs:decimal | op:numeric-subtract(A, B) | xs:decimal
fs:minus(A, B) | xs:float | xs:float | op:numeric-subtract(A, B) | xs:float
fs:minus(A, B) | xs:double | xs:double | op:numeric-subtract(A, B) | xs:double
fs:minus(A, B) | xs:date | xs:date | fn:subtract-dates(A, B) | xs:dayTimeDuration
fs:minus(A, B) | xs:date | xs:yearMonthDuration | op:subtract-yearMonthDuration-from-date(A, B) | xs:date
fs:minus(A, B) | xs:date | xs:dayTimeDuration | op:subtract-dayTimeDuration-from-date(A, B) | xs:date
fs:minus(A, B) | xs:time | xs:time | fn:subtract-times(A, B) | xs:dayTimeDuration
fs:minus(A, B) | xs:time | xs:dayTimeDuration | op:subtract-dayTimeDuration-from-time(A, B) | xs:time
fs:minus(A, B) | xs:dateTime | xs:dateTime | fn:subtract-dateTimes(A, B) | xs:dayTimeDuration
fs:minus(A, B) | xs:dateTime | xs:yearMonthDuration | op:subtract-yearMonthDuration-from-dateTime(A, B) | xs:dateTime
fs:minus(A, B) | xs:dateTime | xs:dayTimeDuration | op:subtract-dayTimeDuration-from-dateTime(A, B) | xs:dateTime
fs:minus(A, B) | xs:yearMonthDuration | xs:yearMonthDuration | op:subtract-yearMonthDurations(A, B) | xs:yearMonthDuration
fs:minus(A, B) | xs:dayTimeDuration | xs:dayTimeDuration | op:subtract-dayTimeDurations(A, B) | xs:dayTimeDuration
fs:times(A, B) | xs:integer | xs:integer | op:numeric-multiply(A, B) | xs:integer
fs:times(A, B) | xs:decimal | xs:decimal | op:numeric-multiply(A, B) | xs:decimal
fs:times(A, B) | xs:float | xs:float | op:numeric-multiply(A, B) | xs:float
fs:times(A, B) | xs:double | xs:double | op:numeric-multiply(A, B) | xs:double
fs:times(A, B) | xs:yearMonthDuration | xs:double | op:multiply-yearMonthDuration(A, B) | xs:yearMonthDuration
fs:times(A, B) | xs:double | xs:yearMonthDuration | op:multiply-yearMonthDuration(B, A) | xs:yearMonthDuration
fs:times(A, B) | xs:dayTimeDuration | xs:double | op:multiply-dayTimeDuration(A, B) | xs:dayTimeDuration
fs:times(A, B) | xs:double | xs:dayTimeDuration | op:multiply-dayTimeDuration(B, A) | xs:dayTimeDuration
fs:idiv(A, B) | xs:integer | xs:integer | op:integer-div(A, B) | xs:integer
fs:div(A, B) | xs:integer | xs:integer | op:numeric-divide(A, B) | xs:double
fs:div(A, B) | xs:decimal | xs:decimal | op:numeric-divide(A, B) | xs:decimal
fs:div(A, B) | xs:float | xs:float | op:numeric-divide(A, B) | xs:float
fs:div(A, B) | xs:double | xs:double | op:numeric-divide(A, B) | xs:double
fs:div(A, B) | xs:yearMonthDuration | xs:double | op:divide-yearMonthDuration(A, B) | xs:yearMonthDuration
fs:div(A, B) | xs:dayTimeDuration | xs:double | op:divide-dayTimeDuration(A, B) | xs:dayTimeDuration
fs:div(A, B) | xs:yearMonthDuration | xs:yearMonthDuration | op:divide-yearMonthDuration-by-yearMonthDuration(A, B) | xs:decimal
fs:div(A, B) | xs:dayTimeDuration | xs:dayTimeDuration | op:divide-dayTimeDuration-by-dayTimeDuration(A, B) | xs:decimal
fs:mod(A, B) | xs:integer | xs:integer | op:numeric-mod(A, B) | xs:integer
fs:mod(A, B) | xs:decimal | xs:decimal | op:numeric-mod(A, B) | xs:decimal
fs:mod(A, B) | xs:float | xs:float | op:numeric-mod(A, B) | xs:float
fs:mod(A, B) | xs:double | xs:double | op:numeric-mod(A, B) | xs:double
fs:eq(A, B) | xs:integer | xs:integer | op:numeric-equal(A, B) | xs:boolean
fs:eq(A, B) | xs:decimal | xs:decimal | op:numeric-equal(A, B) | xs:boolean
fs:eq(A, B) | xs:float | xs:float | op:numeric-equal(A, B) | xs:boolean
fs:eq(A, B) | xs:double | xs:double | op:numeric-equal(A, B) | xs:boolean
fs:eq(A, B) | xs:boolean | xs:boolean | op:boolean-equal(A, B) | xs:boolean
fs:eq(A, B) | xs:string | xs:string | op:numeric-equal(fn:compare(A, B), 0) | xs:boolean
fs:eq(A, B) | xs:date | xs:date | op:date-equal(A, B) | xs:boolean
fs:eq(A, B) | xs:time | xs:time | op:time-equal(A, B) | xs:boolean
fs:eq(A, B) | xs:dateTime | xs:dateTime | op:dateTime-equal(A, B) | xs:boolean
fs:eq(A, B) | xs:duration | xs:duration | op:duration-equal(A, B) | xs:boolean
fs:eq(A, B) | Gregorian | Gregorian | op:gYear-equal(A, B) etc. | xs:boolean
fs:eq(A, B) | xs:hexBinary | xs:hexBinary | op:hex-binary-equal(A, B) | xs:boolean
fs:eq(A, B) | xs:base64Binary | xs:base64Binary | op:base64-binary-equal(A, B) | xs:boolean
fs:eq(A, B) | xs:anyURI | xs:anyURI | op:anyURI-equal(A, B) | xs:boolean
fs:eq(A, B) | xs:QName | xs:QName | op:QName-equal(A, B) | xs:boolean
fs:eq(A, B) | xs:NOTATION | xs:NOTATION | op:NOTATION-equal(A, B) | xs:boolean
fs:ne(A, B) | xs:integer | xs:integer | fn:not(op:numeric-equal(A, B)) | xs:boolean
fs:ne(A, B) | xs:decimal | xs:decimal | fn:not(op:numeric-equal(A, B)) | xs:boolean
fs:ne(A, B) | xs:float | xs:float | fn:not(op:numeric-equal(A, B)) | xs:boolean
fs:ne(A, B) | xs:double | xs:double | fn:not(op:numeric-equal(A, B)) | xs:boolean
fs:ne(A, B) | xs:boolean | xs:boolean | fn:not(op:boolean-equal(A, B)) | xs:boolean
fs:ne(A, B) | xs:string | xs:string | fn:not(op:numeric-equal(fn:compare(A, B), 0)) | xs:boolean
fs:ne(A, B) | xs:date | xs:date | fn:not(op:date-equal(A, B)) | xs:boolean
fs:ne(A, B) | xs:time | xs:time | fn:not(op:time-equal(A, B)) | xs:boolean
fs:ne(A, B) | xs:dateTime | xs:dateTime | fn:not(op:dateTime-equal(A, B)) | xs:boolean
fs:ne(A, B) | xs:duration | xs:duration | fn:not(op:duration-equal(A, B)) | xs:boolean
fs:ne(A, B) | Gregorian | Gregorian | fn:not(op:gYear-equal(A, B)) etc. | xs:boolean
fs:ne(A, B) | xs:hexBinary | xs:hexBinary | fn:not(op:hex-binary-equal(A, B)) | xs:boolean
fs:ne(A, B) | xs:base64Binary | xs:base64Binary | fn:not(op:base64-binary-equal(A, B)) | xs:boolean
fs:ne(A, B) | xs:anyURI | xs:anyURI | fn:not(op:anyURI-equal(A, B)) | xs:boolean
fs:ne(A, B) | xs:QName | xs:QName | fn:not(op:QName-equal(A, B)) | xs:boolean
fs:ne(A, B) | xs:NOTATION | xs:NOTATION | fn:not(op:NOTATION-equal(A, B)) | xs:boolean
fs:gt(A, B) | xs:integer | xs:integer | op:numeric-greater-than(A, B) | xs:boolean
fs:gt(A, B) | xs:decimal | xs:decimal | op:numeric-greater-than(A, B) | xs:boolean
fs:gt(A, B) | xs:float | xs:float | op:numeric-greater-than(A, B) | xs:boolean
fs:gt(A, B) | xs:double | xs:double | op:numeric-greater-than(A, B) | xs:boolean
fs:gt(A, B) | xs:boolean | xs:boolean | op:boolean-greater-than(A, B) | xs:boolean
fs:gt(A, B) | xs:string | xs:string | op:numeric-greater-than(fn:compare(A, B), 0) | xs:boolean
fs:gt(A, B) | xs:date | xs:date | op:date-greater-than(A, B) | xs:boolean
fs:gt(A, B) | xs:time | xs:time | op:time-greater-than(A, B) | xs:boolean
fs:gt(A, B) | xs:dateTime | xs:dateTime | op:dateTime-greater-than(A, B) | xs:boolean
fs:gt(A, B) | xs:yearMonthDuration | xs:yearMonthDuration | op:yearMonthDuration-greater-than(A, B) | xs:boolean
fs:gt(A, B) | xs:dayTimeDuration | xs:dayTimeDuration | op:dayTimeDuration-greater-than(A, B) | xs:boolean
fs:lt(A, B) | xs:integer | xs:integer | op:numeric-less-than(A, B) | xs:boolean
fs:lt(A, B) | xs:decimal | xs:decimal | op:numeric-less-than(A, B) | xs:boolean
fs:lt(A, B) | xs:float | xs:float | op:numeric-less-than(A, B) | xs:boolean
fs:lt(A, B) | xs:double | xs:double | op:numeric-less-than(A, B) | xs:boolean
fs:lt(A, B) | xs:boolean | xs:boolean | op:boolean-less-than(A, B) | xs:boolean
fs:lt(A, B) | xs:string | xs:string | op:numeric-less-than(fn:compare(A, B), 0) | xs:boolean
fs:lt(A, B) | xs:date | xs:date | op:date-less-than(A, B) | xs:boolean
fs:lt(A, B) | xs:time | xs:time | op:time-less-than(A, B) | xs:boolean
fs:lt(A, B) | xs:dateTime | xs:dateTime | op:dateTime-less-than(A, B) | xs:boolean
fs:lt(A, B) | xs:yearMonthDuration | xs:yearMonthDuration | op:yearMonthDuration-less-than(A, B) | xs:boolean
fs:lt(A, B) | xs:dayTimeDuration | xs:dayTimeDuration | op:dayTimeDuration-less-than(A, B) | xs:boolean
fs:ge(A, B) | xs:integer | xs:integer | op:numeric-greater-than(A, B) or op:numeric-equal(A,B) | xs:boolean
fs:ge(A, B) | xs:decimal | xs:decimal | op:numeric-greater-than(A, B) or op:numeric-equal(A,B) | xs:boolean
fs:ge(A, B) | xs:float | xs:float | op:numeric-greater-than(A, B) or op:numeric-equal(A,B) | xs:boolean
fs:ge(A, B) | xs:double | xs:double | op:numeric-greater-than(A, B) or op:numeric-equal(A,B) | xs:boolean
fs:ge(A, B) | xs:boolean | xs:boolean | op:numeric-greater-than(A, B) or op:numeric-equal(A,B) | xs:boolean
fs:ge(A, B) | xs:string | xs:string | op:numeric-greater-than(fn:compare(A, B), -1) | xs:boolean
fs:ge(A, B) | xs:date | xs:date | op:date-less-than(B, A) | xs:boolean
fs:ge(A, B) | xs:time | xs:time | op:time-less-than(B, A) | xs:boolean
fs:ge(A, B) | xs:dateTime | xs:dateTime | op:dateTime-less-than(B, A) | xs:boolean
fs:ge(A, B) | xs:yearMonthDuration | xs:yearMonthDuration | op:yearMonthDuration-less-than(B, A) | xs:boolean
fs:ge(A, B) | xs:dayTimeDuration | xs:dayTimeDuration | op:dayTimeDuration-less-than(B, A) | xs:boolean
fs:le(A, B) | xs:integer | xs:integer | op:numeric-less-than(A, B) or op:numeric-equal(A,B) | xs:boolean
fs:le(A, B) | xs:decimal | xs:decimal | op:numeric-less-than(A, B) or op:numeric-equal(A,B) | xs:boolean
fs:le(A, B) | xs:float | xs:float | op:numeric-less-than(A, B) or op:numeric-equal(A,B) | xs:boolean
fs:le(A, B) | xs:double | xs:double | op:numeric-less-than(A, B) or op:numeric-equal(A,B) | xs:boolean
fs:le(A, B) | xs:boolean | xs:boolean | op:numeric-less-than(A, B) or op:numeric-equal(A,B) | xs:boolean
fs:le(A, B) | xs:string | xs:string | op:numeric-less-than(fn:compare(A, B), 1) | xs:boolean
fs:le(A, B) | xs:date | xs:date | op:date-greater-than(B, A) | xs:boolean
fs:le(A, B) | xs:time | xs:time | op:time-greater-than(B, A) | xs:boolean
fs:le(A, B) | xs:dateTime | xs:dateTime | op:dateTime-greater-than(B, A) | xs:boolean
fs:le(A, B) | xs:yearMonthDuration | xs:yearMonthDuration | op:yearMonthDuration-greater-than(B, A) | xs:boolean
fs:le(A, B) | xs:dayTimeDuration | xs:dayTimeDuration | op:dayTimeDuration-greater-than(B, A) | xs:boolean
fs:is-same-node(A, B) | node() | node() | op:is-same-node | xs:boolean
fs:node-before(A, B) | node() | node() | op:node-before | xs:boolean
fs:node-after(A, B) | node() | node() | op:node-after | xs:boolean

Unary Operators

Internal Function | AtomicType₁ | Denotes | AtomicType₃
fs:unary-plus(A) | xs:integer | op:numeric-unary-plus(A) | xs:integer
fs:unary-plus(A) | xs:decimal | op:numeric-unary-plus(A) | xs:decimal
fs:unary-plus(A) | xs:float | op:numeric-unary-plus(A) | xs:float
fs:unary-plus(A) | xs:double | op:numeric-unary-plus(A) | xs:double
fs:unary-minus(A) | xs:integer | op:numeric-unary-minus(A) | xs:integer
fs:unary-minus(A) | xs:decimal | op:numeric-unary-minus(A) | xs:decimal
fs:unary-minus(A) | xs:float | op:numeric-unary-minus(A) | xs:float
fs:unary-minus(A) | xs:double | op:numeric-unary-minus(A) | xs:double

D Importing Schemas

This section describes how XML Schema declarations, as specified by XML Schema are imported into the [XPath/XQuery] type system.

D.1 Introduction

During schema import processing, the [XPath/XQuery] environment imports XML Schema declarations and loads them as declarations in the [XPath/XQuery] type system. The semantics of that loading process is defined by normalization rules that map XML Schema descriptions into the [XPath/XQuery] type system.

D.1.1 Features

Here is summarized the XML Schema features which are covered by the formal semantics, and handled by the import mapping described in this section. For each feature, the following indications are used.

Handled indicates features that are relevant for [XPath/XQuery], are modeled in the [XPath/XQuery] type system, and are supported by the mapping.

Not in v1.0 indicates features that are relevant to [XPath/XQuery], but are not yet modeled in the [XPath/XQuery] type system or are not handled by the mapping in XQuery V1.0. In case the [XPath/XQuery] type system provides appropriate support for those features, but the mapping is incomplete, the additional annotation mapping only is used.

Not handled indicates features that are relevant for [XPath/XQuery], but are not modeled in the [XPath/XQuery] type system, and are not handled by the mapping. Such features are typically only related to validation, for which the formal semantics defines a partial model.

Ignored Indicates features that are not relevant for [XPath/XQuery], are not modeled in the [XPath/XQuery] type system, and are not relevant for the mapping. Such features might have to do with documentation of the schema, or might affect which Schemas are legal, but do not affect which documents match which Schemas.

Here is the exhaustive list of XML Schema features and their status in this document.

Feature: | Supported
Primitive Simple types | Handled
Simple type derivation by restriction | Handled
Derivation by list and union | Handled
Facets on simple types | Not handled
ID and IDREF constraints | Ignored
Attribute Declarations |
    default,fixed,use | Not in v1.0
Element Declarations |
    default, fixed (value constraint) | Not in v1.0
    nillable | Handled
    substitution group affiliation | Handled
    substitution group exclusions | Ignored
    disallowed substitutions | Ignored
    abstract | Not in v1.0
Complex Type Definitions |
    derivation by restriction | Handled
    derivation by extension | Handled
    final | Ignored
    abstract | Not in v1.0
AttributeUses |
    required | Not in v1.0, mapping only
    default, fixed (value constraint) | Not in v1.0
Attribute Group Definitions | Not in v1.0, mapping only
Model Group Definitions | Not in v1.0, mapping only
Model Groups | Handled
Particles | Handled
Wildcards |
    process contents strict, skip, lax | Ignored
    namespace wild cards. | Ignored
Identity-constraint Definitions | Ignored
Notation Declarations | Ignored
Annotations | Ignored

Note that the schema import feature specified here assumes it is given a legal schema as input. As a result, it is not necessary to check for 'block' or 'abstract' attributes.

D.1.2 Organization

The presentation of the schema mapping is done according to the following organization.

Schema component

First each schema component is summarized using the same notation used in the XML Representation Summary sections in XML Schema. For instance, here is the XML Representation Summary for complex types.

  <complexType

        [ ignored ]   abstract = boolean : false

        [ ignored ]   block = (#all | List of (extension | restriction))

        [ ignored ]   final = (#all | List of (extension | restriction))

        [ ignored ]   id = ID

        mixed = boolean : false

        name = NCName

        [ ignored ]   {any schemaAttributes with non-schema namespace ...} >

        Content: (annotation?, (simpleContent | complexContent | ((group | all | choice | sequence)?, ((schemaAttribute | schemaAttributeGroup)*, anySchemaAttribute?))))

  </complexType>

Attributes indicated as [ ignored ] are not mapped into the [XPath/XQuery] type system.

Attributes indicated as [ not handled ] are not currently handled by the mapping.

Note that in order to simplify the mapping, it is assumed that the default values for all attributes in the XML Representation of Schema are filled in. For instance in the above complex type, if the mixed attribute is not present, it will be treated as being present and having the value "false".

Schema mapping

XML Schema import is specified by means of mapping rules. All mapping rules have the structure below.

[SchemaComponent]Subscript

==

TypeComponent

The SchemaComponent above the horizontal rule denotes an XML Schema component before translation and the TypeComponent beneath the horizontal rule denotes an equivalent type component in the [XPath/XQuery] type system.

Notation

Whenever necessary for the mapping rules, specific grammar productions which describe fragments of XML Schema may be introduced. For instance, here are grammar productions used to describes fragments of the XML Representation Summary for the complexType Element Information Item.

Complex type content

[57 (Formal)]    | ComplexTypeContent |    ::=    | "annotation"? ("simpleContent" | "complexContent" | (ChildrenContent AttributeContent))
[60 (Formal)]    | AttributeContent |    ::=    | ("attribute" | "attributeGroup")* "anyAttribute"?
[58 (Formal)]    | ChildrenContent |    ::=    | ("group" | "all" | "choice" | "sequence")?

As in the rest of this document, some mapping rules may use fragments of the XML Representation corresponding to the syntactic categories defined by those grammar productions. For instance, the following complex type fragment uses the syntactic categories: TypeName, ComplexTypeContent, and AttributeContent, ChildrenContent, and MixedAttribute.

  <complexType

        name = TypeName

        MixedAttribute >

       ChildrenContent AttributeContent

  </complexType>

D.1.3 Main mapping rules

Notation

The normalization rule

[Schema]Schema

==

Definitions

maps a complete schema into a set of Definitions in the [XPath/XQuery] type system.

The normalization rule

[SchemaComponent]definition(targetNCName)

==

Definition

maps a top level schema component into a Definition in the [XPath/XQuery] type system, given the target namespace targetAnyURI.

The normalization rule

[SchemaComponent]content(targetNCName)

==

TypeComponent

maps a schema component not directly under the schema element, into a TypeComponent in the [XPath/XQuery] type system, given the target namespace targetAnyURI.

D.1.4 Special attributes

The XML Schema attributes: use, default, fixed, minOccurs, maxOccurs, mixed, nillable, and substitutionGroup, require specific mapping rules.

D.1.4.1 use, default, and fixed

The "use", "default", and "fixed" attributes are used to describe the occurrence and default behavior of a given attribute.

Notation

The following auxiliary grammar productions are used to describe the "use", "default", and "fixed" attributes.

Use, default, and fixed attributes

[61 (Formal)]    | UseAttribute |    ::=    | "use" "=" ("optional" | "prohibited" | "required")
[62 (Formal)]    | DefaultAttribute |    ::=    | "default" "=" String
[63 (Formal)]    | FixedAttribute |    ::=    | "fixed" "=" String

The normalization rule

[UseAttribute DefaultAttribute? FixedAttribute? ]use

==

OccurrenceIndicator

maps a combination of a use attribute UseAttribute, along with an optional default or fixed attribute in Schema into the occurrence indicator OccurrenceIndicator in the [XPath/XQuery] type system.

Schema mapping

Use attributes are mapped to the type system in the following way. In case there is a default or fixed attribute, the attribute is always present in the PSVI and the use attribute is ignored.

UseAttribute DefaultAttributeuse

==

1

UseAttribute FixedAttributeuse

==

1

use = "optional"use

==

?

use = "required"use

==

1

Editorial note

Issue: how derivation of attribute declaration and the "prohibited" use attributes are mapped in the [XPath/XQuery] type system is still an open issue.

D.1.4.2 minOccurs, maxOccurs, minLength, maxLength, and length

Notation

The following auxiliary grammar productions are used to describe occurrence attributes and the length facets.

Occurrence attributes

[56 (Formal)]    | OccursAttributes |    ::=    | maxOccurs | minOccurs | maxLength | minLength | length
[54 (Formal)]    | maxOccurs |    ::=    | "maxOccurs" "=" ("nonNegativeInteger" | "unbounded")
[55 (Formal)]    | minOccurs |    ::=    | "minOccurs" "=" "nonNegativeInteger"
[51 (Formal)]    | maxLength |    ::=    | "maxLength" "=" "nonNegativeInteger"
[52 (Formal)]    | minLength |    ::=    | "minLength" "=" "nonNegativeInteger"
[53 (Formal)]    | length |    ::=    | "length" "=" "nonNegativeInteger"

The normalization rule

[OccursAttributes ]occurs

==

OccurrenceIndicator

maps the occurrence attributes and facets OccursAttributes in Schema into the occurrence indicator OccurrenceIndicator in the [XPath/XQuery] type system.

Schema mapping

Occurrence attributes are mapped to the type system in the following way.

[minOccurs="0" maxOccurs="1"]occurs

==

?

[minOccurs="1" maxOccurs="1"]occurs

==

[minOccurs="0" maxOccurs="n"]occurs

==

*

[minOccurs="1" maxOccurs="n"]occurs

==

+

where n > 1.

[minOccurs="n" maxOccurs="m"]occurs

==

+

where m >= n > 1

[minLength="0" maxLength="1"]occurs

==

?

[minLength="1" maxLength="1"]occurs

==

[minLength="0" maxLength="n"]occurs

==

*

[minLength="1" maxLength="n"]occurs

==

+

where n > 1.

[minLength="n" maxLength="m"]occurs

==

+

where m >= n > 1

[length="1"]occurs

==

[length="n"]occurs

==

+

where n > 1

D.1.4.3 mixed

Notation

The following auxiliary grammar productions are used to describe the "mixed" attribute.

Mixed attribute

[48 (Formal)]   
MixedAttribute
   ::=   
"mixed" "=" Boolean

The normalization rule

[MixedAttribute]mixed

==

Mixed

maps the mixed attribute MixedAttribute in Schema into a Mixed notation in the [XPath/XQuery] type system.

Schema mapping

If the mixed attribute is true it is mapped to a mixed notation in the [XPath/XQuery] type system.

[ mixed = "true" ]mixed

==

mixed

If the mixed attribute is false it is mapped to empty in the [XPath/XQuery] type system.

[ mixed = "false" ]mixed

==

D.1.4.4 nillable

Notation

The following auxiliary grammar productions are used to describe the "nillable" attribute.

Nillable attribute

[49 (Formal)]   
NillableAttribute
   ::=   
"nillable" "=" Boolean

The normalization rule

[NillableAttribute]nillable

==

Nillable

maps the nillable attribute NillableAttribute in Schema into a Nillable notation in the [XPath/XQuery] type system.

Schema mapping

If the nillable attribute is true it is mapped to a nillable notation in the [XPath/XQuery] type system.

[ nillable = "true" ]nillable

==

nillable

If the nillable attribute is false it is mapped to empty in the [XPath/XQuery] type system.

[ nillable = "false" ]nillable

==

D.1.4.5 substitutionGroup

Notation

The substitution group declaration indicates the element that a given element can be substituted for. The following auxiliary grammar productions are used to describe the "substitutionGroup" attribute.

substitutionGroup attribute

[50 (Formal)]   
substitutionGroupAttribute
   ::=   
"substitutionGroup" "=" QName

The normalization rule

[substitutionGroupAttribute]substitution

==

Substitution

maps the substitutionGroup attribute substitutionGroupAttribute in Schema into a Substitution notation in the [XPath/XQuery] type system.

Schema mapping

If the substitutionGroup attribute is present, it is mapped to a substitutionGroup notation in the [XPath/XQuery] type system.

[ substitutionGroup = QName ]substitution

==

substitutes for QName

Otherwise, it is mapped to empty.

D.1.5 Anonymous type names

Notation

As explained in [2.4 The [XPath/XQuery] Type System], the [XPath/XQuery] type uses system-generated type names for anonymous types. For the purpose of this document those type names are generated at XML Schema import time.

D.2 Schemas as a whole

D.2.1 Schema

Schema component

A schema is represented in XML by the following structure.

  <schema

        [ not handled ]   attributeFormDefault = (qualified | unqualified) : unqualified

        [ ignored ]   blockDefault = (#all | List of (extension | restriction | substitution)) : ' '

        [ not handled ]   elementFormDefault = (qualified | unqualified) : unqualified

        [ ignored ]   finalDefault = (#all | List of (extension | restriction)) : ' '

        [ ignored ]   id = ID

        targetNamespace = anyURI

        [ ignored ]   version = token

        [ ignored ]   xml:lang = language

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: ((include | import | redefine | annotation)*, (((simpleType | complexType | group | attributeGroup) | element | attribute | notation), annotation*)*)

  </schema>

Notation

The following auxiliary grammar productions are used.

XML Schema Pragma and Content

[46 (Formal)]    | SPragma |    ::=    | ("include" | "import" | "redefine" | "annotation")*
[47 (Formal)]    | Content |    ::=    | (("simpleType" | "complexType" | "element" | "attribute" | "attributeGroup" | "group" | "notation") "annotation"*)*

The auxiliary normalization rule

[Pragma]pragma(targetAnyURI)

==

Definitions

maps the a schema pragma into a set of definitions in the [XPath/XQuery] type system.

Schema mapping

Schemas are imported by the "schema" declaration in the preamble of a query. To import a schema, the document referred to by the given URI is opened and the schema declarations contained in the document are translated into the corresponding in-line type definitions. The mechanism for finding a schema document, possibly using the optional schema location hint, is not specified formally.

[schema StringLiteral (at StringLiteral)?]Schema

==

[open-schema-document(StringLiteral (at StringLiteral)?)]Schema

[

  <schema

        targetNamespace = targetAnyURI >

        Pragma Content

  </schema>

]Schema

==

[Pragma]pragma(targetAnyURI) [Content]definition(targetNCName)

D.2.2 Include

Schema component

A schema include is represented in XML by the following structure.

  <include

        [ ignored ]   id = ID

        schemaLocation = anyURI

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?)

  </include>

Schema mapping

A schema include is not specified here, and is assumed to be handled by the XML Schema processor.

D.2.3 Redefine

Schema component

A schema redefinition is represented in XML by the following structure.

  <redefine

        [ ignored ]   id = ID

        schemaLocation = anyURI

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation | (simpleType | complexType | group | attributeGroup))*

  </redefine>

Schema mapping

A schema redefine is not specified here, and is assumed to be handled by the XML Schema processor.

D.2.4 Import

Schema component

A schema import is represented in XML by the following structure.

  <import

        [ ignored ]   id = ID

        namespace = anyURI

        schemaLocation = anyURI

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?)

  </import>

Schema mapping

A schema import is not specified here, and is assumed to be handled by the XML Schema processor.

D.3 Attribute Declarations

Schema component

The following structure describes attribute declarations in XML Schema.

  <attribute

        [ not handled ]   default = string

        [ not handled ]   fixed = string

        [ not handled ]   form = (qualified | unqualified)

        [ ignored ]   id = ID

        name = NCName

        ref = QName

        type = QName

        use = (optional | prohibited | required) : optional

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, (simpleType?))

  </attribute>

D.3.1 Global attributes declarations

Schema import distinguishes between global attribute declarations and local attribute declarations.

Schema mapping

Global attribute declarations are mapped like local attribute declarations, but are prefixed by a "define" keyword in the [XPath/XQuery] type system.

[AttributeDecl]definition(targetNCName)

==

define [AttributeDecl]content(targetNCName)

D.3.2 Local attribute declarations

Schema mapping

Local attributes whose type is given by a reference to a global type name are mapped in the type system as follows.

[

  <attribute

        name = NCName

        type = QName

        UseAttribute  />

]content(targetNCName)

==

( attribute targetNCName:NCName { of type QName } )[UseAttribute]use

References to a global attribute are mapped in the type system as follows.

[

  <attribute

        ref = QName

        UseAttribute  />

]content(targetNCName)

==

( attribute QName )[UseAttribute]use

A local attribute with a local content is mapped to the [XPath/XQuery] type system as follows. Let fs:anonk be a newly generated anonymous name.

[

  <attribute

        name = NCName

        UseAttribute >

        simpleType

  </attribute>

]content(targetNCName)

==

( attribute targetNCName:NCName of type fs:anonk )[UseAttribute]use

  with

define type fs:anonk of type xs:anySimpleType { [simpleType]content(targetNCName) }

D.4 Element Declarations

Schema component

The following structure describes attribute declarations in XML Schema.

  <element

        [ ignored ]   abstract = boolean : false

        [ ignored ]   block = (#all | List of (extension | restriction))

        [ not handled ]   default = string

        [ ignored ]   final = (#all | List of (extension | restriction))

        [ not handled ]   fixed = string

        [ not handled ]   form = (qualified | unqualified)

        [ ignored ]   id = ID

        maxOccurs = (nonNegativeInteger | unbounded) : 1

        minOccurs = nonNegativeInteger : 1

        name = NCName

        nillable = boolean : false

        ref = QName

        substitutionGroup = QName

        type = QName

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, ((simpleType | complexType)?, (unique | key | keyref)*))

  </element>

D.4.1 Global element declarations

Schema import distinguishes between global element declarations and local element declarations.

Schema mapping

Global element declarations are mapped like local element declarations, but are prefixed by a "define" keyword in the [XPath/XQuery] type system.

[

  <element

        name = NCName

        NillableAttribute

        substitutionGroupAttribute

        type = QName  />

]definition(targetNCName)

==

define element targetNCName:NCName [substitutionGroupAttribute]substitution [NillableAttribute]nillable of type QName

[

  <element

        name = NCName

        NillableAttribute

        substitutionGroupAttribute >

        ElementModel

  </element>

]definition(targetNCName)

==

define element targetNCName:NCName [substitutionGroupAttribute]substitution [NillableAttribute]nillable [ElementModel]content(targetNCName)

D.4.2 Local element declarations

Schema mapping

Local element declarations, but mapped into corresponding notations in the [XPath/XQuery] type system. Note that substitution group cannot be declared on local elements.

[

  <element

        OccursAttributes

        name = NCName

        NillableAttribute

        type = QName  />

]content(targetNCName)

==

( element targetNCName:NCName [NillableAttribute]nillable of type QName ) [OccursAttributes ]occurs

[

  <element

        OccursAttributes

        ref = QName  />

]content(targetNCName)

==

( element QName ) [OccursAttributes ]occurs

Let fs:anonk be a newly generated anonymous name.

[

  <element

        OccursAttributes

        name = NCName

        NillableAttribute >

        ElementModel

  </element>

]definition(targetNCName)

==

( element targetNCName:NCName [NillableAttribute]nillable of type fs:anonk ) [OccursAttributes ]occurs

  with

define type fs:anonk [ElementModel]content(targetNCName) }

D.5 Complex Type Definitions

Schema component

A complex type definition is represented in XML by the following structure.

  <complexType

        [ ignored ]   abstract = boolean : false

        [ ignored ]   block = (#all | List of (extension | restriction))

        [ ignored ]   final = (#all | List of (extension | restriction))

        [ ignored ]   id = ID

        mixed = boolean : false

        name = NCName

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, (simpleContent | complexContent | ((group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?))))

  </complexType>

Notation

The following auxiliary grammar productions are used to describe the content of a complex type definition.

Complex type content

[57 (Formal)]    | ComplexTypeContent |    ::=    | "annotation"? ("simpleContent" | "complexContent" | (ChildrenContent AttributeContent))
[60 (Formal)]    | AttributeContent |    ::=    | ("attribute" | "attributeGroup")* "anyAttribute"?
[58 (Formal)]    | ChildrenContent |    ::=    | ("group" | "all" | "choice" | "sequence")?

D.5.1 Global complex type

Schema import distinguishes between global complex types (which are mapped to sort declarations) and local complex types (which are mapped to type definitions).

Schema mapping

In the case of global complex types, the mapping rule which applies is denoted by []definition(targetNCName).

[

  <complexType

        MixedAttribute

        name = NCName >

        ComplexTypeContent

  </complexType>

]definition(targetNCName)

==

define type targetNCName:NCName [MixedAttribute ComplexTypeContent]mixed_content(targetNCName)

Note that the mixed is passed along in the normalization rules, in order to map it later on to the appropriate indication in the [XPath/XQuery] type system.

D.5.2 Local complex type

Schema mapping

In the case of a local complex types, there must not be a name attribute and the mapping rule which applies is denoted by []content(targetNCName).

[

  <complexType

        MixedAttribute >

        ComplexTypeContent

  </complexType>

]content(targetNCName)

==

[MixedAttribute ComplexTypeContent]mixed_content(targetNCName)

Note that the mixed is passed along in the normalization rules, in order to map it later on to the appropriate indication in the [XPath/XQuery] type system.

D.5.3 Complex type with simple content

Schema component

A complex type can be of simple content. A simple content is represented in XML by the following structure.

  <simpleContent

        [ ignored ]   id = ID

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, (restriction | extension))

  </simpleContent>

Derivation by restriction inside a simple content is represented in XML by the following structure.

  <restriction

        base = QName

        [ ignored ]   id = ID

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, (simpleType?, (minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | length | minLength | maxLength | enumeration | whiteSpace | pattern)*)?, ((attribute | attributeGroup)*, anyAttribute?))

  </restriction>

Derivation by extension inside a simple content is represented in XML by the following structure.

  <extension

        base = QName

        [ ignored ]   id = ID

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, ((attribute | attributeGroup)*, anyAttribute?))

  </extension>

Notation

The normalization rule

[MixedAttribute ComplexTypeContent]mixed_content(targetNCName)

==

TypeDerivation

maps a pair of mixed attribute and complex type content to a type derivation.

Schema mapping

A complex types with simple content must not have a mixed attribute set to "true".

If the simple content is derived by restriction, it is mapped into a simple type restriction in the [XPath/XQuery] type system. Only the name of the base atomic type and attributes are mapped, while the actual simple type restriction is ignored. (Remember that facets are not captured in the [XPath/XQuery] type system.)

[

mixed = "false"

  <simpleContent>

  <restriction

        base = QName >

        simpleContentRestriction AttributeContent

  </restriction>

  </simpleContent>

]mixed_content(targetNCName)

==

restricts QName { [AttributeContent]content(targetNCName) QName }

If the simple type is derived by extension, it is mapped into an extended type specifier into the [XPath/XQuery] type system.

[

mixed = "false"

  <simpleContent>

  <extension

        base = QName >

        AttributeContent

  </extension>

  </simpleContent>

]mixed_content(targetNCName)

==

extends QName { [AttributeContent]content(targetNCName) }

D.5.4 Complex type with complex content

Schema component

A complex type can be of complex content. A complex content is represented in XML by the following structure.

  <complexContent

        [ ignored ]   id = ID

        mixed = boolean : false

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, (restriction | extension))

  </complexContent>

Derivation by restriction inside a complex content is represented in XML by the following structure.

  <restriction

        base = QName

        [ ignored ]   id = ID

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, (group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?))

  </restriction>

Derivation by extension inside a complex content is represented in XML by the following structure.

  <extension

        base = QName

        [ ignored ]   id = ID

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, ((group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?)))

  </extension>

Schema mapping

If the complex content is derived by restriction, it is mapped into a type restriction in the [XPath/XQuery] type system, and the

[

MixedAttribute

  <complexContent>

  <restriction

        base = QName >

        annotation? ChildrenContent AttributeContent

  </restriction>

  </complexContent>

]mixed_content(targetNCName)

==

restricts QName [MixedAttribute]mixed { [AttributeContent]content(targetNCName) [ChildrenContent]content(targetNCName) }

If the complex content is derived by extension, it is mapped into an extended type specifier into the [XPath/XQuery] type system.

[

MixedAttribute

  <complexContent>

  <extension

        base = QName >

        annotation? ChildrenContent AttributeContent

  </extension>

  </complexContent>

]mixed_content(targetNCName)

==

extends QName [MixedAttribute]mixed { [AttributeContent]content(targetNCName) [ChildrenContent]content(targetNCName) }

D.6 Attribute Uses

Mapping for attribute uses is given in [D.1.4 Special attributes].

D.7 Attribute Group Definitions

D.7.1 Attribute group definitions

Schema component

Model group definitions are represented in XML by the following structure.

  <attributeGroup

        [ ignored ]   id = ID

        name = NCame

        ref = QName

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, ((attribute | attributeGroup)*, anyAttribute?))

  </attributeGroup>

Schema mapping

Attribute group definitions are not currently handled by the mapping. See Issue 501 (FS-Issue-0158).

D.7.2 Attribute group reference

Schema mapping

Attribute group references are not currently handled by the mapping. See Issue 501 (FS-Issue-0158).

D.8 Model Group Definitions

Schema component

Model group definitions are represented in XML by the following structure.

  <group

        name = NCame >

        Content: (annotation?, (all | choice | sequence))

  </group>

Schema mapping

Model group definitions are not currently handled by the mapping. See Issue 501 (FS-Issue-0158).

D.9 Model Groups

Model groups are either "all", "sequence" or "choice". One can also refer to a model group definition.

D.9.1 All groups

Schema component

All groups are represented in XML by the following structure.

  <all

        [ ignored ]   id = ID

        maxOccurs = 1 : 1

        minOccurs = (0 | 1) : 1

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, element*)

  </all>

Schema mapping

All groups are mapped into the "&" operation in the [XPath/XQuery] type system.

[

  <all

        OccursAttributes >

        Element₁ ... Elementn

  </all>

]content(targetNCName)

==

([Element₁]content(targetNCName) & ... & [Elementn]content(targetNCName)) [OccursAttributes ]occurs

D.9.2 Choice groups

Schema component

Choice groups are represented in XML by the following structure.

  <choice

        [ ignored ]   id = ID

        maxOccurs = (nonNegativeInteger | unbounded) : 1

        minOccurs = nonNegativeInteger : 1

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, (element | group | choice | sequence | any)*)

  </choice>

Notation

The following auxiliary grammar productions are used to describe group components.

Group Component

[59 (Formal)]   
GroupComponent
   ::=   
"element" | "group" | "choice" | "sequence" | "any"

Schema mapping

Choice groups are mapped into the "|" operation in the [XPath/XQuery] type system.

[

  <choice

        OccursAttributes >

        GroupComponent₁ ... GroupComponentn

  </choice>

]content(targetNCName)

==

([GroupComponent₁]content(targetNCName) | ... | [GroupComponentn]content(targetNCName)) [OccursAttributes ]occurs

D.9.3 Sequence groups

Schema component

Sequence groups are represented in XML by the following structure.

  <sequence

        [ ignored ]   id = ID

        maxOccurs = (nonNegativeInteger | unbounded) : 1

        minOccurs = nonNegativeInteger : 1

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, (element | group | choice | sequence | any)*)

  </sequence>

Schema mapping

Sequence groups are mapped into the "," operation in the [XPath/XQuery] type system.

[

  <sequence

        OccursAttributes >

        GroupComponent₁ ... GroupComponentn

  </sequence>

]content(targetNCName)

==

([GroupComponent₁]content(targetNCName) , ... , [GroupComponentn]content(targetNCName)) [OccursAttributes ]occurs

D.10 Particles

Particles contribute to the definition of content models.

A particle can be either an element reference, a group reference or a wildcard.

D.10.1 Element reference

Schema component

Element reference particles are represented in XML by the following structure.

  <element

        ref = QName

        maxOccurs = (nonNegativeInteger | unbounded) : 1

        minOccurs = nonNegativeInteger : 1

        [ ignored ]   {any attributes with non-schema namespace ...} >

Schema mapping

Element references are mapped into element references in the [XPath/XQuery] type system.

[

  <element

        ref = QName

        OccursAttributes  />

]content(targetNCName)

==

element QName [OccursAttributes ]occurs

D.10.2 Group reference

Schema component

Group reference particles are represented in XML by the following structure.

  <group

        ref = QName

        maxOccurs = (nonNegativeInteger | unbounded) : 1

        minOccurs = nonNegativeInteger : 1

        [ ignored ]   {any attributes with non-schema namespace ...} >

Schema mapping

Model group references are not currently handled by the mapping.

D.11 Wildcards

D.11.1 Attribute wildcards

Schema component

Attribute wildcards are represented in XML by the following structure.

  <anyAttribute

        [ ignored ]   id = ID

        [ not handled ]   namespace = ((##any | ##other) | List of (anyURI | (##targetNamespace | ##local)) ) : ##any

        processContents = (lax | skip | strict) : strict

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?)

  </anyAttribute>

Schema mapping

An attribute wildcard with a "skip" process content is mapped as an attribute wildcard in the [XPath/XQuery] type system.

[

  <anyAttribute

        processContents = "skip" >

        annotation?

  </anyAttribute>

]content(targetNCName)

==

(attribute (*, xs:untypedAtomic))*

[

  <anyAttribute

        processContents = "lax" >

        annotation?

  </anyAttribute>

]content(targetNCName)

==

attribute *

[

  <anyAttribute

        processContents = "strict" >

        annotation?

  </anyAttribute>

]content(targetNCName)

==

attribute *

Editorial note

Namespace wildcards are not handled by the mapping.

D.11.2 Element wildcards

Schema component

Element wildcards are represented in XML by the following structure.

  <any

        [ ignored ]   id = ID

        maxOccurs = (nonNegativeInteger | unbounded) : 1

        minOccurs = nonNegativeInteger : 1

        [ not handled ]   namespace = ((##any | ##other) | List of (anyURI | (##targetNamespace | ##local)) ) : ##any

        processContents = (lax | skip | strict) : strict

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?)

  </any>

Schema mapping

An element wildcard with a "skip" process content is mapped as an element wildcard in the [XPath/XQuery] type system.

[

  <any

        OccursAttributes

        processContents = "skip" >

        annotation?

  </any>

]content(targetNCName)

==

( element (*, xs:untyped) )[OccursAttributes ]occurs

[

  <any

        OccursAttributes

        processContents = "lax" >

        annotation?

  </any>

]content(targetNCName)

==

( element (*, xs:anyType) )[OccursAttributes ]occurs

Editorial note

Element wildcards with a "lax" or "strict" process content are not handled by the mapping.

Editorial note

Namespace wildcards are not handled by the mapping.

D.12 Identity-constraint Definitions

All identity-constraints definitions are ignored when mapping into the [XPath/XQuery] type system.

D.13 Notation Declarations

All notation declarations are ignored when mapping into the [XPath/XQuery] type system.

D.14 Annotation

All annotation are ignored when mapping into the [XPath/XQuery] type system.

D.15 Simple Type Definitions

Schema component

A simple type is represented in XML by the following structure.

  <simpleType

        [ ignored ]   final = (#all | (list | union | restriction))

        [ ignored ]   id = ID

        name = NCName

        [ ignored ]   {any attributes with non-schema namespace ...} >

        name = NCName

  </simpleType>

Derivation by restriction inside a simple type is represented in XML by the following structure.

  <restriction

        base = QName

        [ ignored ]   id = ID

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, (simpleType?, (minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | length | minLength | maxLength | enumeration | whiteSpace | pattern)*)?)

  </restriction>

Derivation by list inside a simple type is represented in XML by the following structure.

  <list

        [ ignored ]   id = ID

        itemType = QName

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, (simpleType?))

  </list>

Derivation by union inside a simple type is represented in XML by the following structure.

  <union

        [ ignored ]   id = ID

        memberTypes = List of QName

        [ ignored ]   {any attributes with non-schema namespace ...} >

        Content: (annotation?, (simpleType*))

  </union>

D.15.1 Global simple type definition

Schema import distinguishes between global simple types (which are mapped to sort declarations) and local simple types (which are mapped to type definitions).

Schema mapping

In the case of global simple types, the mapping rule which applies is denoted by []definition(targetNCName).

[

  <simpleType

        name = NCName >

        SimpleTypeContent

  </simpleType>

]definition(targetNCName)

==

define type targetNCName:NCName [SimpleTypeContent]simple_content(targetNCName)

D.15.2 Local simple type definition

Schema mapping

In the case of global simple types, the mapping rule which applies is denoted by []content(targetNCName).

[

  <simpleType>

SimpleTypeContent

  </simpleType>

]content(targetNCName)

==

[SimpleTypeContent]simple_content(targetNCName)

D.15.3 Simple type content

Notation

The normalization rule []simple_content(targetNCName) maps a simple type content to a type specifier and an optional occurrence indicator.

Schema mapping

If the simple type is derived by restriction, it is mapped into a simple type restriction in the [XPath/XQuery] type system. The name of the base atomic type and attributes are mapped. Only the minLength, maxLength, and length facets in the simple type restriction are handled. All other properties of the simple-type restriction are ignored.

[

  <restriction

        base = QName >

        simpleContentRestriction

  </restriction>

]simple_content(targetNCName)

==

restricts QName { QName } [simpleContentRestriction]occurs

If the simple type is derived by list, and its content type does not constrain the length of the list, it is mapped into a zero-or-more repetition type into the [XPath/XQuery] type system.

[

  <list>

SimpleType

  </list>

]simple_content(targetNCName) Type = [SimpleType]content(targetNCName)

==

{ Type * }

If the simple type is derived by list, and its content type does constrain the length of the list, then it is mapped into a zero-or-more repetition type into the [XPath/XQuery] type system.

[

  <list>

SimpleType

  </list>

]simple_content(targetNCName) Type · OccurrenceIndicator = [SimpleType]content(targetNCName)

==

{ Type · OccurrenceIndicator }

[

  <list

        itemType = QName  />

]simple_content(targetNCName)

==

{ QName* }

If the simple type is derived by union, it is mapped into a union type into the [XPath/XQuery] type system.

[

  <union>

SimpleType₁ ... SimpleTypen

  </union>

]simple_content(targetNCName)

==

{ ([SimpleType]content(targetNCName) | ... | [SimpleTypen]content(targetNCName)) }

[

  <union

        memberTypes = QName₁ ... QNamen  />

]simple_content(targetNCName)

==

{ QName₁ | ... | QNamen }

E References

E.1 Normative References

XML

Extensible Markup Language (XML) 1.0 (Fourth Edition), Eve Maler, Jean Paoli, François Yergeau, et. al., Editors. World Wide Web Consortium, 16 Aug 2006. This version is http://www.w3.org/TR/2006/REC-xml-20060816. The latest version is available at http://www.w3.org/TR/xml.

XML Names 1.1

World Wide Web Consortium. Namespaces in XML 1.1. W3C Recommendation. See http://www.w3.org/TR/xml-names11/

Schema Part 1

XML Schema Part 1: Structures Second Edition, Henry S. Thompson, David Beech, Noah Mendelsohn, and Murray Maloney, Editors. World Wide Web Consortium, 28 Oct 2004. This version is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/. The latest version is available at http://www.w3.org/TR/xmlschema-1/.

Schema Part 2

XML Schema Part 2: Datatypes Second Edition, Paul V. Biron and Ashok Malhotra, Editors. World Wide Web Consortium, 28 Oct 2004. This version is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. The latest version is available at http://www.w3.org/TR/xmlschema-2/.

Data Model

XQuery 1.0 and XPath 2.0 Data Model (XDM), Norman Walsh, Mary Fernández, Ashok Malhotra, et. al., Editors. World Wide Web Consortium, 23 Jan 2007. This version is http://www.w3.org/TR/2007/REC-xpath-datamodel-20070123/. The latest version is available at http://www.w3.org/TR/xpath-datamodel/.

Data Model Serialization

XSLT 2.0 and XQuery 1.0 Serialization, Joanne Tong, Michael Kay, Norman Walsh, et. al., Editors. World Wide Web Consortium, 23 Jan 2007. This version is http://www.w3.org/TR/2007/REC-xslt-xquery-serialization-20070123/. The latest version is available at http://www.w3.org/TR/xslt-xquery-serialization/.

XQuery 1.0: An XML Query Language

XQuery 1.0: An XML Query Language, Don Chamberlin , Anders Berglund, Scott Boag, et. al., Editors. World Wide Web Consortium, 23 Jan 2007. This version is http://www.w3.org/TR/2007/REC-xquery-20070123/. The latest version is available at http://www.w3.org/TR/xquery/.

XML Path Language (XPath) 2.0

XML Path Language (XPath) 2.0, Don Chamberlin , Anders Berglund, Scott Boag, et. al., Editors. World Wide Web Consortium, 23 Jan 2007. This version is http://www.w3.org/TR/2007/REC-xpath20-20070123/. The latest version is available at http://www.w3.org/TR/xpath20/.

Functions and Operators

XQuery 1.0 and XPath 2.0 Functions and Operators, Ashok Malhotra, Jim Melton, and Norman Walsh, Editors. World Wide Web Consortium, 23 Jan 2007. This version is http://www.w3.org/TR/2007/REC-xpath-functions-20070123/. The latest version is available at http://www.w3.org/TR/xpath-functions/.

E.2 Non-normative References

XML Schema Part 0

XML Schema Part 0: Primer Second Edition, David C. Fallside and Priscilla Walmsley, Editors. World Wide Web Consortium, 28 Oct 2004. This version is http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/. The latest version is available at http://www.w3.org/TR/xmlschema-0/.

XML Query 1.0 Requirements

XML Query (XQuery) Requirements, Don Chamberlin, Peter Fankhauser, Massimo Marchiori, and Jonathan Robie, Editors. World Wide Web Consortium, 3 Jun 2005. This version is http://www.w3.org/TR/2005/WD-xquery-requirements-20050603/. The latest version is available at http://www.w3.org/TR/xquery-requirements/.

E.3 Background References

Languages

Handbook of Formal Languages. G. Rozenberg and A. Salomaa, editors. Springer-Verlag. 1997.

TATA

Tree Automata Techniques and Applications. H. Comon and M. Dauchet and R. Gilleron and F. Jacquemard and D. Lugiez and S. Tison and M. Tommasi. See http://www.grappa.univ-lille3.fr/tata/. 1997.

F Auxiliary Judgments for Validation (Non-Normative)

F.1 Judgments for the validate expression

XQuery supports XML Schema validation using the validate expression. This section gives a non-normative formal semantics of XML Schema validation, solely for the purpose of specifying its usage in XQuery.

Specifying XML Schema validation requires a fairly large number of auxiliary judgments. There are two main judgments used to describe the semantics of validation.

The "erase" judgment takes a value and removes all type information from it. This operation is necessary since, in XQuery, validation can occur both on well-formed or already validated documents.

The "annotate" operation takes an untyped value and a type and either fails or succeeds by returning a new -validated- value.

Before defining these two judgments, we first introduce the auxiliary judgments used to describe specific parts of XML Schema's semantics.

F.1.1 Type resolution

Notation

The judgments

statEnv |-  TypeReference resolves to TypeName { Type }

and

statEnv |-  TypeDerivation resolves to TypeName { Type }

hold when a type reference (resp. a type derivation) resolves to the given type name and type content.

Semantics

Those judgments are specified by the following rules.

If the type is omitted, it is resolved as the empty sequence type.

statEnv |-  Derivation? OptMixed { empty } resolves to TypeName { Type }

statEnv |-  Derivation? OptMixed { } resolves to TypeName { Type }

In case of a type reference, then the type name is the name of that type, and the type is taken by resolving the type declaration of the global type.

statEnv |-  TypeName of elem/type expands to expanded-QName

statEnv.typeDefn(expanded-QName) = define type TypeName TypeDerivation

statEnv |-  TypeDerivation resolves to BaseTypeName { Type }

statEnv |-  of type TypeName resolves to TypeName { Type }

In the above inference rule, note that BaseTypeName is the base type of the type referred to. So this is indeed the original type name, TypeName, which must be returned, and eventually used to annotated the corresponding element or attribute. However, the type needs to be obtained through a second application of the resolves to judgment.

If the type derivation is a restriction, then the type name is the name of the base type, and the type is taken from the type derivation.

statEnv |-  OptMixed Type adjusts to AdjustedType

statEnv |-  restricts TypeName OptMixed { Type } resolves to TypeName { AdjustedType }

If the type derivation is an extension, then the type name is the name of the base type, and the type is the base type extended by the type in the type derivation.

statEnv |-  TypeName of elem/type expands to expanded-QName

statEnv.typeDefn(expanded-QName) = define type TypeName Derivation? BaseOptMixed { BaseType? }

statEnv |-  BaseType? extended by Type is ExtendedType

statEnv |-  OptMixed ExtendedType adjusts to AdjustedType

statEnv |-  extends TypeName OptMixed { Type } resolves to TypeName { AdjustedType }

F.1.2 Interleaving

Notation

The judgment

statEnv |-  Value₁ interleave Value₂ yields Value₃

holds if some interleaving of Value₁ and Value₂ yields Value₃. Interleaving is non-deterministic; it is used for processing all groups.

Semantics

This judgment is specified by the following rules.

Interleaving two empty sequences yields the empty sequence.

statEnv |-  () interleave () yields ()

Otherwise, pick an item from the head of one of the sequences, and recursively interleave the remainder.

statEnv |-  Value₁ interleave Value₂ yields Value₃

statEnv |-  Item,Value₁ interleave Value₂ yields Item,Value₃

statEnv |-  Value₁ interleave Value₂ yields Value₃

statEnv |-  Value₁ interleave Item,Value₂ yields Item,Value₃

F.1.3 Attribute filtering

Introduction

Finally, we introduce an auxiliary judgment which extracts the value of a given attribute if it exists. This judgment is not used in the semantics of step expressions, but in [8.3 Judgments for type matching], and is based on the other filter judgments.

Notation

The judgment

Value filter @QName => absent

holds if there are no occurrences of the attribute QName in Value. The judgment

Value filter @QName => SimpleValue

holds if there is one occurrence of the attribute QName in Value, and the value of that attribute is SimpleValue.

Semantics

The filter judgments are defined as follows.

dynEnv |-  axis attribute:: of Value₁ => Value₂

dynEnv |-  test QName with attribute of Value₂ => ()

Value₁ filter @QName => absent

dynEnv |-  axis attribute:: of Value₁ => Value₂

dynEnv |-  test QName with attribute of Value₂ => Value₃

Value₃ = attribute QName { SimpleValue }

Value₁ filter @QName => SimpleValue

F.1.4 Erasure

F.1.4.1 Simply erases

Notation

To define erasure, an auxiliary judgment is needed. The judgment

SimpleValue simply erases to String

holds when SimpleValue erases to the string String.

Semantics

This judgment is specified by the following rules.

The empty sequence erases to the empty string.

() simply erases to ""

The concatenation of two non-empty sequences of values erases to the concatenation of their erasures with a separating space.

SimpleValue₁ simply erases to String₁

SimpleValue₁ != ()

SimpleValue₂ simply erases to String₂

SimpleValue₂ != ()

SimpleValue₁,SimpleValue₂ simply erases to fn:concat(String₁," ",String₂)

An atomic value erases to its string representation as an instance of xs:untypedAtomic.

AtomicValueContent of type AtomicTypeName simply erases to dm:string-value(AtomicValueContent)

F.1.4.2 Erases

Notation

The erases to judgment is used in the definition of the dynamic semantics of validation. The normative dynamic semantics of validation is specified in Section 3.13 Validate ExpressionsXQ. The effect of the validate expression is equivalent to:

serialization of the data model, as described in [Data Model Serialization], followed by

validation of the serialized value into a Post-Schema Validated Infoset, as described in [Schema Part 1], followed by

construction of a new data model value, as described in [Data Model].

Erasure is the formal equivalent of serialization followed by construction of a new data model value in which all element nodes are labeled with xs:untyped and all attribute nodes with xs:untypedAtomic.

The judgment

Value₁ erases to Value₂

holds when the erasure of Value₁ is Value₂.

Semantics

This judgment is specified by the following rules.

The empty sequence erases to itself.

() erases to ()

The erasure of the concatenation of two values is the concatenation of their erasure, so long as neither of the two original values is simple.

Value₁ erases to Value₁'      statEnv |-  Value₁ not a simple value

Value₂ erases to Value₂'      Value₂ not a simple value

Value₁,Value₂ erases to Value₁',Value₂'

The erasure of an element is an element that has the same name and the type xs:untyped and the erasure of the original content.

Value₁ erases to Value₂

element ElementName of type TypeName { Value₁ } erases to element ElementName of type xs:untyped { Value₂ }

The erasure of an attribute is an attribute that has the same name and the type xs:untypedAtomic and the simple erasure of the original content labeled with xs:untypedAtomic.

SimpleValue simply erases to String

attribute AttributeName of type TypeName { SimpleValue } erases to attribute AttributeName of type xs:untypedAtomic { String of type xs:untypedAtomic }

The erasure of a document is a document with the erasure of the original content.

Value₁ erases to Value₂

document { Value₁ } erases to document { Value₂ }

The erasure of a text or comment or processing-instruction node is itself.

text { String } erases to text { String }

comment { String } erases to comment { String }

processing-instruction NCName { String } erases to processing-instruction NCName { String }

The erasure of a simple value is the corresponding text node.

SimpleValue simply erases to String

SimpleValue erases to text { String }

F.1.5 Annotate

The annotate as judgment is used in the definition of the dynamic semantics of validation. The normative dynamic semantics of validation is specified in Section 3.13 Validate ExpressionsXQ. The effect of the validate expression is equivalent to:

serialization of the data model, as described in [Data Model Serialization], followed by

parsing of the serialized value into the Infoset

validation of the Infoset into a Post-Schema Validated Infoset, as described in [Schema Part 1], followed by

construction of a new data model value, as described in [Data Model].

Annotation is the formal equivalent of schema validation of an Infoset value into the PSVI followed by construction of a new data model value. Because the Formal Semantics is defined on data model values, not the Infoset, annotation is applied to data model values in which all element nodes are labeled with xs:untyped and all attribute nodes with xs:untypedAtomic -- that is, the result of erasure.

F.1.5.1 Simply annotate

Notation

The judgment

statEnv |-  simply annotate as SimpleType ( SimpleValue ) => SimpleValue₂

holds if the result of casting the SimpleValue₁ to SimpleType is SimpleValue₂.

Semantics

This judgment is specified by the following rules.

Simply annotating a simple value to a union type yields the result of simply annotating the simple value to either the first or second type in the union. Note that simply annotating to the second type is attempted only if simply annotating to the first type fails.

statEnv |-  simply annotate as SimpleType₁ (SimpleValue₁) => SimpleValue₂

statEnv |-  simply annotate as SimpleType₁|SimpleType₂ (SimpleValue₁) => SimpleValue₂

statEnv |-  not(simply annotate as SimpleType₁ (SimpleValue₁) => SimpleValue₂)

statEnv |-  simply annotate as SimpleType₂ (SimpleValue₁) => SimpleValue₂

statEnv |-  simply annotate as SimpleType₁|SimpleType₂ (SimpleValue₁) => SimpleValue₂

The simple annotation rules for ?, +, * are similar.

statEnv |-  simply annotate as SimpleType? ( () ) => ()

statEnv |-  simply annotate as SimpleType (SimpleValue₁) => SimpleValue₂

statEnv |-  simply annotate as SimpleType? (SimpleValue₁) => SimpleValue₂

statEnv |-  simply annotate as SimpleType* ( () ) => ()

statEnv |-  simply annotate as SimpleType (SimpleValue₁) => SimpleValue₁'

statEnv |-  simply annotate as SimpleType* (SimpleValue₂) => SimpleValue₂'

statEnv |-  simply annotate as SimpleType* (SimpleValue₁,SimpleValue₂) => SimpleValue₁',SimpleValue₂'

statEnv |-  simply annotate as SimpleType (SimpleValue₁) => SimpleValue₁'

statEnv |-  simply annotate as SimpleType* (SimpleValue₂) => SimpleValue₂'

statEnv |-  simply annotate as SimpleType+ (SimpleValue₁,SimpleValue₂) => SimpleValue₁',SimpleValue₂'

Simply annotating an atomic value to xs:string yields its string representation.

statEnv |-  simply annotate as xs:string (AtomicValue) => dm:string-value(AtomicValue)

Simply annotating an atomic value to xs:decimal yields the decimal that results from parsing its string representation.

statEnv |-  simply annotate as xs:decimal (AtomicValue) => xs:decimal(dm:string-value( AtomicValue))

Similar rules are assumed for the rest of the 19 XML Schema primitive types.

F.1.5.2 Nil-annotate

Notation

The judgment

statEnv |-  nil-annotate as OptNillable Type ( Value₁ ) => Value₂

holds if it is possible to annotate value Value₁ as if it had the nillable type Type and Value₂ is the corresponding annotated value.

Semantics

This judgment is specified by the following rules.

If the type is not nillable, then the xsi:nil attribute must not appear in the value, and it must be possible to annotate value Value as if it had the type Type.

Value₁ filter @xsi:nil => absent

statEnv |-  annotate as Type ( Value₁ ) => Value₂

statEnv |-  nil-annotate as Type ( Value₁ ) => Value₂

If the type is nillable, and the xsi:nil attribute does not appear or is false, then it must be possible to annotate value Value₁ as if it had the type Type.

Value₁ filter @xsi:nil => SimpleValue

SimpleValue in { (), false }

statEnv |-  annotate as Type ( Value₁ ) => Value₂

statEnv |-  nil-annotate as nillable Type ( Value₁ ) => Value₂

If the type is nillable, and the xsi:nil attribute is true, then it must be possible to annotate value Value₁ as if it had a type where the attributes in the type are kept and the element content of the type is ignored.

Value₁ filter @xsi:nil => true

statEnv |-  annotate as AttributeModel ( Value₁ ) => Value₂

statEnv |-  nil-annotate as nillable (AttributeModel, ElementModel) ( Value₁ ) => Value₂

F.1.5.3 Annotate

The annotate as judgment is used in the definition of the dynamic semantics of validation. The normative dynamic semantics of validation is specified in Section 3.13 Validate ExpressionsXQ. The effect of the validate expression is equivalent to:

serialization of the data model, as described in [Data Model Serialization], followed by

parsing of the serialized value into the Infoset

validation of the Infoset into a Post-Schema Validated Infoset, as described in [Schema Part 1], followed by

construction of a new data model value, as described in [Data Model].

Erasure is the formal equivalent of serialization followed by construction of a new data model value in which all element nodes are labeled with xs:untyped and all attribute nodes with xs:untypedAtomic.

Notation

The judgment

statEnv |-  annotate as Type ( Value₁ ) => Value₂

holds if it is possible to annotate value Value₁ as if it had type Type and Value₂ is the corresponding annotated value.

Note

Assume an XML Infoset instance X1 is validated against an XML Schema S, yielding PSVI instance X2. Then if X1 corresponds to Value₁ and S corresponds to Type and X2 corresponds to Value₂, the following should hold: annotate as Type ( Value₁ ) => Value₂.

Semantics

This judgment is specified by the following rules.

Annotating the empty sequence as the empty type yields the empty sequence.

statEnv |-  annotate as empty (()) => ()

Annotating a concatenation of values as a concatenation of types yields the concatenation of the annotated values.

statEnv |-  annotate as Type₁ (Value₁) => Value₁'

statEnv |-  annotate as Type₂ (Value₂) => Value₂'

statEnv |-  annotate as Type₁,Type₂ (Value₁,Value₂) => Value₁',Value₂'

Annotating a value as a choice type yields the result of annotating the value as either the first or second type in the choice.

statEnv |-  annotate as Type₁ (Value₁) => Value₂

statEnv |-  annotate as Type₁|Type₂ (Value₁) => Value₂

statEnv |-  annotate as Type₂ (Value₁) => Value₂

statEnv |-  annotate as Type₁|Type₂ (Value₁) => Value₂

Annotating a value as an all group uses interleaving to decompose the original value and recompose the annotated value.

Editorial note

Jerome and Phil: Note that this may reorder the original sequence. Perhaps we should disallow such reordering. Specifying that formally is not as easy as we would like.

statEnv |-  annotate as Type₁ ( Value₁ ) => Value₁'

statEnv |-  annotate as Type₂ ( Value₂ ) => Value₂'

statEnv |-  Value₁ interleave Value₂ yields Value

statEnv |-  Value₁' interleave Value₂' yields Value'

statEnv |-  annotate as Type₁ & Type₂ ( Value ) => Value'

The annotation rules for ?, +, * are similar.

statEnv |-  annotate as (Type | empty)(Value₁) => Value₂

statEnv |-  annotate as Type? (Value₁) => Value₂

statEnv |-  annotate as Type (Value₁) => Value₁'      statEnv |-  annotate as Type* (Value₂) => Value₂'

statEnv |-  annotate as Type+ (Value₁,Value₂) => (Value₁',Value₂')

statEnv |-  annotate as Type* ( () ) => ()

statEnv |-  annotate as Type (Value₁) => Value₁'      statEnv |-  annotate as Type* (Value₂) => Value₂'

statEnv |-  annotate as Type* (Value₁,Value₂) => (Value₁',Value₂')

To annotate an element with no xsi:type attribute, first look up the element type, next resolve the resulting type reference, then annotate the value against the resolved type, and finally return a new element with the name of the original element, the resolved type name, and the annotated value.

Value filter @xsi:type => ()

statEnv |-  ElementName name lookup ElementType yields OptNillable TypeReference

statEnv |-  TypeReference resolves to TypeName { Type }

statEnv |-  nil-annotate as OptNillable Type (Value) => Value'

statEnv |-  annotate as ElementType ( element ElementName of type xs:anyType { Value } ) => element ElementName of type TypeName { Value' }

To annotate an element with an xsi:type attribute, define a type reference corresponding to the xsi:type. Look up the element type, yielding a type reference, and check that the xsi:type reference derives from this type reference. Resolve the xsi:type reference, then annotate the value against the resolved type, and finally return a new element with the name of the original element, the resolved type name, and the annotated value.

Value filter @xsi:type => TypeName

XsiTypeReference = of type TypeName

statEnv |-  ElementName name lookup ElementType yields OptNillable of type BaseTypeName

statEnv |-  TypeName derives from BaseTypeName

statEnv |-  XsiTypeReference resolves to TypeName { Type }

statEnv |-  nil-annotate as OptNillable Type (Value) => Value'

statEnv |-  annotate as ElementType ( element ElementName of type xs:anyType { Value } ) => element ElementName of type TypeName { Value' }

The rule for attributes is similar to the first rule for elements.

statEnv |-  AttributeName name lookup AttributeType yields TypeReference

statEnv |-  TypeReference resolves to TypeName { Type }

statEnv |-  nil-annotate as OptNillable Type (SimpleValue₁) => SimpleValue₂

statEnv |-  annotate as AttributeType ( attribute AttributeName of type xs:anySimpleType { SimpleValue₁ } ) => attribute AttributeName of type TypeName { SimpleValue₂ }

Annotating a document node yields a document with the annotation of its contents.

statEnv |-  annotate as Type (Value) => Value'

statEnv |-  annotate as document { Type } ( document { Value } ) => document { Value' }

Annotating a text node as text yields itself.

statEnv |-  annotate as text (text { String }) => text { String }

Annotating a text nodes as a simple type is identical to casting.

statEnv |-  simply annotate as SimpleType ( String ) => SimpleValue'

statEnv |-  annotate as SimpleType ( text { String } ) => SimpleValue'

Annotating a simple value as a simple type is identical to casting.

statEnv |-  simply annotate as SimpleType ( SimpleValue ) => SimpleValue'

statEnv |-  annotate as SimpleType ( SimpleValue ) => SimpleValue'

G Revision Log (Non-Normative)

This appendix lists the changes that have been made to this specification since the publication of the Proposed Recommendation Draft on 21 November 2006.

Fixed a number of typos and editorial issues throughout the document.