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 document, and are marked with (XQuery). For instance, the following production describes FLWOR expressions in XQuery.

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 , and are marked with (XPath). For instance, the following production describes for expressions in XPath.

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

The Formal Semantics manipulates objects (values, types, expressions, etc.) for which there is no existing grammar production in the document. In these cases, specific grammar productions are introduced. Notably, additional productions are used to describe values in the , 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.

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 inference rules (see the next section). As a convenience, non-terminals used in inference rules link to the appropriate grammar production.

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

For example:

A judgment can contain symbols and patterns.

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

Patterns are written with italicized words. The name of a pattern is significant: each pattern name corresponds to an object (a value, a type, an expression, etc.) that can be substituted legally for the pattern. By convention, all patterns in the Formal Semantics correspond to grammar non-terminals, and are used to represent entities that can be constructed through application of the corresponding grammar production. For example, Expr represents any [XPath/XQuery] expression, and Value represents any value in the [XPath/XQuery] data model.

When applying 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 the value '3' (on the right-hand side of the => symbol).

Patterns may appear with subscripts (e.g. Expr1, Expr2) to distinguish different instances of the same sort of pattern. Each distinct pattern must be instantiated to a single object (value, type, expression, etc.). If the same pattern occurs twice in a judgment description then it should be instantiated with the same object. For example, '3 => 3' is an instance of the judgment 'Expr1 => Expr1' but '$x+0 => 3' is not since the two expressions '$x+0' and '3' cannot be both instance of the pattern Expr1. The judgment'$x+0 => 3' is an instance of the judgment 'Expr1 => Expr2'.

Patterns may have a name that is not exactly the name of a grammar production but is based on it. For instance, a BaseTypeName is a pattern that stands for a type name, as would TypeName, or TypeName2. This usage is limited, and only occurs to improve the readability of some of the inference rules.

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

In some cases, an object may take a value within a finite set of pre-determined values. We may write those set of possible value using the in judgment. For instance, the judgment

which holds, if the object Color has either the value blue or the value green.

Inference rules are used to specify whether a 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:

All premises and the conclusion are judgments. The interpretation of an inference rule is: if all the premise judgments above the line hold, then the conclusion judgment below the line also hold.

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

This inference rule expresses the following property of the judgment 'Expr => Value': 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:

This inference rule expresses the following property of the judgment 'Expr => Value': evaluating the literal expression '3' always yields the value '3'.

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

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

Logical inference rules use environments to record information computed during static type analysis or dynamic evaluation so that this information can be used by other logical inference rules. For example, the type signature of a user-defined function in a [expression/query] prolog can be recorded in an environment and used by subsequent rules. Similarly, the value assigned to a variable within a "let" expression can be captured in an environment and accessed later on during evaluation when that variable is accessed.

An environment 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 or update the environment.

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

This document uses environment groups that group related environments. If group is an environment group with the environment component env, then that environment is denoted group.env and the value that symbol is mapped to is denoted group.env(symbol).

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

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

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

For instance, the judgment

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

Environment groups can be updated, using the following notation:

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 group 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

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

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

Putting the above notations together, here is an example of an inference rule that occurs later in this document:

This rule is read as follows: if two expressions Expr1 and Expr2 are known to have the static types Type1 and Type2 (the two premises above the line), then it is the case that the expression below the line Expr1 , Expr2 must have the static type Type1, Type2, which is the sequence of types Type1 and Type2. The above inference rule does not modify the (static) environment.

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

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

Each inference rule describes a fragment of the semantics for a given expression. Here is how those rules are combined. Consider the following expression.

We have just seen the static typing rule for the let clause and sequence construction. To handle this expression completely, we need inference rules for integer literals and variable access. Those two rules are as follows.

With this set of rules, we can compute the type of the expression above in a bottom-up fashion, i.e., starting with the sub-expressions. The resulting type inference proceeds as follows.

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

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 , xdt:untypedAtomic, or xdt:anyAtomicType.

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

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

A simple value is a sequence of atomic values.

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

A 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:anon0, fs:anon1, etc.

Formal values are defined by the following grammar.

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

An element has an optional nilled marker. This marker can only be present 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.

In examples, we omit the namespace bindings when they are empty. For example, the following two values are the same (note that the xs and xdt prefixes are built-in):

The same rule about constructing sequences apply to the values described by that grammar. Notably sequences are automatically flattened. For example, the sequence (10, (1, 2), (), (3, 4)) is equivalent to the sequence (10, 1, 2, 3, 4). Those rules are described in more details in .

When the context is clear, we may omit the on literal values. For instance:

A well-formed document

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

A document before and after validation.

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

After validation, this element is represented as:

An element with a list type

Before validation, this element is represented as:

Assume the following Schema.

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

An element with an anonymous type

Before validation, this element is represented as:

Assume the following Schema.

After validation, this element is represented as:

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

A nillable element with xsi:type set to true:

Before validation, this element is represented as:

Assume the following Schema.

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

An element with a union type

Before validation, this element is represented as:

Assume the following Schema:

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

The [XPath/XQuery] type system is based on and . and 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 . 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 . The rest of this section is organized as follows. describes item types, describes content models, and describe top-level type declarations.

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.

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

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

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 .

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 Type1 & Type2 matches any sequence that is an interleaving of a sequence that matches Type1 and a sequence that matches Type2. The interleaved product captures the semantics of all groups in XML Schema, but it more general has 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.

The "&" operator builds the interleaved product of two types. The type Type1 & Type2 matches any sequence that is an interleaving of two sequences of items, the first one matching Type1 and the second matching Type2. Where the interleaving of two sequences of items Value1 and Value2 is any sequence Value0 such that there is an ordered partition of Value0 into the two sub-sequences Value1 and Value2.

For example, consider the types Type1 = xs:integer,xs:integer,xs:integer and Type2 = xs:string,xs:string. Value1 = (1,2,3) matches the type Type1 and Value2 = ("a","b") matches the type Type2. Any of the following Value0 are interleavings of Value1 and Value2, and therefore match the type (Type1 & Type2):

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

Parenthesis can be used to enforce precedence. For instance

is equivalent to

and a different precedence can be obtained by writing

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

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

is represented as follows

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 repetion of the item type. For instance, the two following simple type declarations

are represented as follows

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

is respresented as follow

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

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

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.

Here is a schema describing purchase orders from .

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

Note that the two anonymous types in the item element declarations are mapping to types with names fs:anon1 and fs:anon2.

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.

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

The environment group statEnv denotes the environments that are 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 environments are part of the static environment group: