W3C

XQuery 1.0 and XPath 2.0 Formal Semantics

W3C Working Draft 15 November 2002

This version:
http://www.w3.org/TR/2002/WD-query-semantics-20021115/
Latest version:
http://www.w3.org/TR/query-semantics/
Previous versions:
http://www.w3.org/TR/2002/WD-query-semantics-20020816/
http://www.w3.org/TR/2002/WD-query-semantics-20020326/
http://www.w3.org/TR/2001/WD-query-semantics-20010607/
http://www.w3.org/TR/2001/WD-query-algebra-20010215/
http://www.w3.org/TR/2000/WD-query-algebra-20001204/
Editors:
Denise Draper (XML Query WG), Nimble Technology <ddraper@nimble.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), Microsoft <ashokma@microsoft.com>
Kristoffer Rose (XSL WG), IBM Research <krisrose@us.ibm.com>
Michael Rys (XML Query WG), Microsoft <mrys@microsoft.com>
Jérôme Siméon (XML Query WG), Lucent Technologies <simeon@research.bell-labs.com>
Philip Wadler (XML Query WG), Avaya <wadler@avaya.com>

Abstract

This document defines the formal semantics of XQuery 1.0 [XQuery 1.0: A Query Language for XML] and XPath 2.0 [XML Path Language (XPath) 2.0].

Status of this Document

This is a public W3C Working Draft for review by W3C Members and other interested parties. This section describes the status of this document at the time of its publication. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress." A list of current public W3C technical reports can be found at http://www.w3.org/TR/.

This document is a work in progress. It contains many open issues, and should not be considered to be fully stable. Vendors who wish to create preview implementations based on this document do so at their own risk. While this document reflects the general consensus of the working groups, there are still controversial areas that may be subject to change.

Among the most important changes from the previous version of this document are:

A complete list of issues is maintained in [D Issues]. The following are identified as high priority issues.

Public comments on this document and its open issues are welcome. Comments should be sent to the W3C XPath/XQuery mailing list, public-qt-comments@w3.org (archived at http://lists.w3.org/Archives/Public/public-qt-comments/).

XQuery 1.0, XPath 2.0, and their formal semantics has been defined jointly by the XML Query Working Group (part of the XML Activity) and the XSL Working Group (part of the Style Activity).

Patent disclosures relevant to this specification may be found on the XML Query Working Group's patent disclosure page at http://www.w3.org/2002/08/xmlquery-IPR-statements and the XSL Working Group's patent disclosure page at http://www.w3.org/Style/XSL/Disclosures.

Table of Contents

1 Introduction
2 Preliminaries
    2.1 Processing model
    2.2 Namespaces
    2.3 Data Model
        2.3.1 Data model overview
        2.3.2 Node identity
        2.3.3 Document order and sequence order
        2.3.4 Type annotations and anonymous types
    2.4 Schemas and types
        2.4.1 The elements of a (statically) typed language
        2.4.2 XML Schema and the XQuery type system
        2.4.3 Structural and named typing
        2.4.4 Subtyping
            2.4.4.1 Type substitutability
            2.4.4.2 Subtyping and XML Schema derivation
    2.5 Functions
        2.5.1 Functions and operators
        2.5.2 Functions and static typing
        2.5.3 The error function
        2.5.4 Data Model Accessors
        2.5.5 Other Formal Semantics functions
    2.6 Notations
        2.6.1 Grammar productions
        2.6.2 Judgments
        2.6.3 Inference rules
        2.6.4 Environments
        2.6.5 Putting it together
    2.7 The Formal Semantics
        2.7.1 Normalization
        2.7.2 Static type inference
        2.7.3 Dynamic Evaluation
        2.7.4 Formal Semantics internal links
3 The XQuery type system
    3.1 Values
    3.2 Types
        3.2.1 Item types
        3.2.2 Content models
        3.2.3 Top level definitions
        3.2.4 Built-in type declarations
        3.2.5 Syntactic constraints on types
        3.2.6 Example
    3.3 Judgments for name hierarchies
        3.3.1 Derives
        3.3.2 Substitutes
    3.4 Judgments for type matching
        3.4.1 Element and attribute lookup
        3.4.2 Matches
        3.4.3 Subtype
    3.5 Judgments for sequences of item types
    3.6 Judgments for the typeswitch expression
    3.7 Judgments for type promotion
    3.8 Judgments for the validate expression
        3.8.1 Builtin attributes
        3.8.2 Extension
        3.8.3 Mixed content
        3.8.4 Adjusts
        3.8.5 Type resolution
        3.8.6 Element and attribute lookup
        3.8.7 Interleaving
        3.8.8 Filtering
        3.8.9 Structural matching
            3.8.9.1 Structural nil matching
            3.8.9.2 Structural matching
        3.8.10 Erasure
            3.8.10.1 Simply erases
            3.8.10.2 Erases
        3.8.11 Annotate
            3.8.11.1 Simply annotate
            3.8.11.2 Nil-annotate
            3.8.11.3 Annotate
4 Basics
    4.1 Expression Context
        4.1.1 Static Context
        4.1.2 Evaluation Context
    4.2 Input Functions
    4.3 Expression Processing
    4.4 Types
        4.4.1 Type Checking
        4.4.2 SequenceType
            4.4.2.1 SequenceType Matching
        4.4.3 Type Conversions
            4.4.3.1 Atomization
            4.4.3.2 Effective Boolean Value
    4.5 Variable Bindings
    4.6 Errors and Conformance
5 Expressions
    5.1 Primary Expressions
        5.1.1 Literals
        5.1.2 Variables
        5.1.3 Parenthesized Expressions
        5.1.4 Function Calls
        5.1.5 Comments
    5.2 Path Expressions
        5.2.1 Steps
            5.2.1.1 Axes
            5.2.1.2 Node Tests
        5.2.2 Predicates
        5.2.3 Unabbreviated Syntax
        5.2.4 Abbreviated Syntax
    5.3 Sequence Expressions
        5.3.1 Constructing Sequences
        5.3.2 Combining Sequences
    5.4 Arithmetic Expressions
    5.5 Comparison Expressions
        5.5.1 Value Comparisons
        5.5.2 General Comparisons
        5.5.3 Node Comparisons
        5.5.4 Order Comparisons
    5.6 Logical Expressions
    5.7 Constructors
        5.7.1 Element Constructors
        5.7.2 Computed Element and Attribute Constructors
            5.7.2.1 Computed Text Nodes
            5.7.2.2 Computed Document Nodes
            5.7.2.3 Computed Element Nodes
            5.7.2.4 Constructed Attribute Nodes
        5.7.3 Whitespace in Constructors
        5.7.4 Other Constructors and Comments
    5.8 [For/FLWOR] Expressions
        5.8.1 FLWR expressions
        5.8.2 For expression
        5.8.3 Let Expression
        5.8.4 Order By
    5.9 Unordered Expressions
    5.10 Conditional Expressions
    5.11 Quantified Expressions
    5.12 Expressions on SequenceTypes
        5.12.1 Instance Of
        5.12.2 Typeswitch
        5.12.3 Cast
        5.12.4 Castable
        5.12.5 Constructor Functions
        5.12.6 Treat as
    5.13 Validate Expressions
6 The Query Prolog
    6.1 Namespace Declarations
    6.2 Schema Imports
    6.3 Xmlspace Declaration
    6.4 Default Collation
    6.5 Function Definitions
7 Additional Semantics of Functions
    7.1 Formal Semantics Functions
        7.1.1 The fs:characters-to-string function
        7.1.2 The fs:distinct-doc-order function
        7.1.3 The fs:item-sequence-to-node-sequence function
        7.1.4 The fs:item-sequence-to-string function
    7.2 Functions with specific typing rules
        7.2.1 The fn:error function
        7.2.2 The fn:distinct-nodes, and fn:distinct-values functions
        7.2.3 The op:union, op:intersect and op:except operators
        7.2.4 The op:to operator
        7.2.5 The fn:data function
8 Importing Schemas
    8.1 Introduction
        8.1.1 Features
        8.1.2 Organization
        8.1.3 Main mapping rules
        8.1.4 Special attributes
            8.1.4.1 use
            8.1.4.2 minOccurs and maxOccurs
            8.1.4.3 mixed
            8.1.4.4 nillable
            8.1.4.5 substitutionGroup
        8.1.5 Anonymous type names
    8.2 Attribute Declarations
        8.2.1 Global attributes declarations
        8.2.2 Local attribute declarations
    8.3 Element Declarations
        8.3.1 Global element declarations
        8.3.2 Local element declarations
    8.4 Complex Type Definitions
        8.4.1 Global complex type
        8.4.2 Local complex type
        8.4.3 Complex type with simple content
        8.4.4 Complex type with complex content
    8.5 Attribute Uses
    8.6 Attribute Group Definitions
        8.6.1 Attribute group definitions
        8.6.2 Attribute group reference
    8.7 Model Group Definitions
    8.8 Model Groups
        8.8.1 All groups
        8.8.2 Choice groups
        8.8.3 Sequence groups
    8.9 Particles
        8.9.1 Element reference
        8.9.2 Group reference
    8.10 Wildcards
        8.10.1 Attribute wildcards
        8.10.2 Element wildcards
    8.11 Identity-constraint Definitions
    8.12 Notation Declarations
    8.13 Annotation
    8.14 Simple Type Definitions
        8.14.1 Global simple type definition
        8.14.2 Local simple type definition
        8.14.3 Simple type content
    8.15 Schemas as a whole
        8.15.1 Schema
        8.15.2 Include
        8.15.3 Redefine
        8.15.4 Import

Appendices

A Normalized core grammar
    A.1 Core lexical structure
        A.1.1 Syntactic Constructs
    A.2 Core BNF
B Mapping of Overloaded Internal Functions
C References
    C.1 Normative References
    C.2 Non-normative References
    C.3 Background References
D Issues
    D.1 Introduction
    D.2 Issues list
    D.3 Alphabetic list of issues
        D.3.1 Open Issues
        D.3.2 Resolved (or redundant) Issues
    D.4 Delegated Issues
        D.4.1 XPath 2.0
        D.4.2 XQuery
        D.4.3 Operators


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:

Ed. Note: [Kristoffer/XSL] The role of the formal semantics document could be clarified: does it supplement or subsume the language specification in case of conflict?

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

[XPath/XQuery] is a powerful language, capable of selecting and extracting complex patterns from XML documents , reformulating them into results in arbitrary ways, and computing expressions over the result. This document defines the semantics of [XPath/XQuery] by giving a precise formal meaning to each of the constructions 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.

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. It is built from expressions, rather than statements. Every construct in the language (except for the 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 aspect of the functional approach is that variables are always passed by value and their value cannot be modified through side-effects.

[XPath/XQuery] is a typed language. Types can be imported from one or more XML Schemas describing the documents that will be processed, and the [XPath/XQuery] language can then perform operations based on these types (e.g., using a treat as operation). In addition, [XPath/XQuery] also supports a level of static type analysis. This means the system can infer the output type of an expression, based on the type of its inputs. Static typing allows early error detection, and can be used as the basis for certain forms of optimization. The type system of [XPath/XQuery] is based on [XML Schema]. The [XPath/XQuery] type system models most of the features of [XML 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.

The [XPath/XQuery] formal semantics builds on long-standing traditions in the database and in the programming languages communities. In particular, the [XPath/XQuery] formal semantics has been inspired by works on SQL [SQL], OQL [ODMG], [BKD90], [CM93], and nested relational algebra (NRA) [BNTW95], [Col90], [LW97], [LMW96]. Other references include Quilt [Quilt], UnQL [BFS00], XDuce [HP2000], XML-QL [XMLQL99], XPath 1.0 [XML Path Language (XPath) : Version 1.0], XQL [XQL99], XSLT [XSLT 99], and YATL [YAT99]. Additional related work can be found in the bibliography [C References].

This document is organized as follows. [2 Preliminaries] introduces notations used to define the [XPath/XQuery] formal semantics. [3 The XQuery type system] describes the [XPath/XQuery] type system, operations on the [XPath/XQuery] type system, and explains the relationship between the [XPath/XQuery] type system and XML Schema. [4 Basics] describes semantics for basic [XPath/XQuery] concepts, and [5 Expressions], describes the dynamic and static semantics of [XPath/XQuery] expressions. [6 The Query Prolog] describes the semantics of the [XPath/XQuery] prolog. [7 Additional Semantics of Functions] describes any additional semantics required for [XPath/XQuery] functions. Finally, [8 Importing Schemas], specifies how XML Schemas are imported into the [XPath/XQuery] type system.

2 Preliminaries

This section provides the background necessary to understand the [XPath/XQuery] Formal Semantics and introduces the notations that are used.

2.1 Processing model

First, a processing model for [expression/query] evaluation is defined. 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.

The processing model consists of five phases; each phase consumes the result of the previous phase and generates output for the next phase. For each processing phase, we furthermore point to the relevant notations introduced later in the document.

  1. Parsing. The grammar for the [XPath/XQuery] syntax is defined in [XQuery 1.0: A Query Language for XML]. Parsing may generate syntax errors. If no error occurs, an internal representation of the parsed syntax tree corresponding to the query is created: this ensures that we can unambiguously specify the following phases by a case per syntax production.

  2. Context Processing. The semantics of [expression/query] depends on the input context. The input context needs to be generated before the [expression/query] can be processed. In XQuery, the input context is described in the Query Prolog (See [6 The Query Prolog]). In XPath, the input context is generated by the processing environment. The input context is split in a static and a dynamic part (denoted statEnv and dynEnv, respectively).

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

    During the normalization phase, each [XPath/XQuery] [expression/query] is mapped into its equivalent [expression/query] in the core. (Note that this has nothing to do with Unicode Normalization, which works on character strings.) Normalization works by bottom-up application of normalization rules over expressions, starting with normalization of literals.

    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 [2.7.1 Normalization].

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

  4. Static type analysis. Static type analysis checks whether each [expression/query] is type safe, and if so, determines its static type. Static type analysis is defined only for Core [expression/query]. Static type analysis works by bottom-up application of type inference rules over expressions, taking the type of literals and the known types of input documents into account.

    If the [expression/query] is not type-safe, static type analysis can result in a type error. For instance, a comparison between an integer value and a string value might be detected as an error during the static type analysis. If static type analysis succeeds, it results in a syntax tree where each sub-expression is "decorated" with its static type, and in an output type for the result of the [expression/query].

    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 [2.7.2 Static type inference].

    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.

  5. Dynamic Evaluation. This is the phase in which the result of the [expression/query] is computed. The semantics of evaluation is defined only for Core [expression/query] terms. Evaluation works by bottom-up application of evaluation rules over expressions, starting with evaluation of literals. Evaluation may result in a value OR a dynamic error (or, once static typing is made optional, in a type error).

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

Ed. Note: Issue:[Kristoffer/XSL] The distinction between errors manifest by not being able to prove a judgment and special error values is not clear. Also the processing model does not allow for skipping static typing. See [Issue-0094:  Static type errors and warnings], [Issue-0171:  Raising errors], and [Issue-0169:  Conformance Levels].

The first four phases above are "analysis-time" (sometimes also called "compile-time") steps, which is to say that they can be performed on a [expression/query] before examining any input document. Indeed, analysis-time processing can be performed before such document even exists. Analysis-time processing can detect many errors early-on, e.g., syntax errors or type errors. If no error occurs, the result of analysis-time processing could be some compiled form of [expression/query], suitable for execution by a compiled-[expression/query] processor. The last phase is an "execution-time" (sometimes also called "run-time") step, which is to say that the query is evaluated on actual input document(s).

Static 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 execution time. For instance, whether an arithmetic expression on 32 bits integers (xs:int) yields an out-of-bound value can only be detected at run-time by looking at the data.

While implementations may be free to employ 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. Statically typed implementations are required to find and report static type errors, as specified in this document. It is still an open issue (See [Issue-0098:  Implementation of and conformance levels for static type checking]) whether to make the static type analysis phase optional to allow implementations to return a result for a type-invalid [expression/query] in special cases where the [expression/query] happens to perform correctly on a particular instance of input data. (Note that this is not the same as merely permitting that the static type error is emitted at evaluation time as is done below.)

Notice that the separation of logical processing into phases is not meant to imply that implementations must separate analysis-time from evaluation-time processing: [expression/query] processors may choose to perform all phases simultaneously at evaluation-time and may even mix the phases in their internal implementations. The processing model defines only what the final result.

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

  1. XML Schema import phase. The [XPath/XQuery] type system is based on XML Schema. In order to perform static type analysis, 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 [8 Importing Schemas].

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

  3. Serialization phase. 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 still an open issue (See [Issue-0116:  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: A Query Language for XML] 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.

For the other three phases (normalization, static type analysis and evaluation), instead or giving an algorithm in pseudo-code, the semantics is described formally by means of inference rules. Inference rules provide a notation to describe how the semantics of an expression derives from the semantics of its sub-expressions. Hence, they provide a concise and precise way for specifying bottom-up algorithms, as required by the normalization, static type analysis, and evaluation phases.

2.2 Namespaces

The Formal Semantics uses the following namespace prefixes.

The accessors and constructors defined by the data model are shown with the prefix dm. Some special functions, variables and types used in the Formal Semantics are shown with the prefix fs. Those prefixes are always shown in italics to emphasize that the corresponding functions, variables, and types are abstract: they are not and cannot be made accessible directly from the host language.

All these prefixes are assumed to be bound to the appropriate URIs.

2.3 Data Model

2.3.1 Data model overview

This section gives an overview of the main data model features that are relevant to the Formal Semantics. The reader is referred to the [XQuery 1.0 and XPath 2.0 Data Model] document for more details.

  • An atomic value is a value in the value space of one of the [XML Schema Part 2] atomic types (that is, a primitive simple type that is not derived by list or union).

  • A node is one of the following kinds: document, element, attribute, namespace, comment, processing-instruction and text. The [XPath/XQuery] Formal Semantics does not currently discuss namespace, comment, and processing-instruction nodes (See [Issue-0105:  Types for nodes in the data model.]). Components of nodes can be typed values, string values, names, type annotations, or other nodes.

  • XML documents and their contents are represented in the data model as trees composed of nodes and atomic values. [XQuery 1.0 and XPath 2.0 Data Model] defines a mapping from the PSVI (Post Schema Validation Information Set) to such trees.

  • [XQuery 1.0 and XPath 2.0 Data Model] defines constructors, which are functions that construct nodes and atomic values, and accessors, which are functions that access a value's properties or components.

    For instance, the children function returns all the child nodes of an element node. The typed value of a node is a sequence of zero or more atomic values. The string value of a node is an instance of the type xs:string. The name of a node is an instance of the type xs:QName.

  • An item is either an atomic value or a node.

  • Every value in the data model is a sequence. A sequence is an ordered collection of zero or more items. Sequences are represented by items separated by commas, enclosed in parentheses.

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

  • The data model annotates element nodes, attribute nodes, and atomic values with type names. This type annotation is the type name given to the element, attribute, or value through the validation process.

The remainder of the section is devoted to several related features that merit special attention: node identity, order, and type annotations.

2.3.2 Node identity

In the [XQuery 1.0 and XPath 2.0 Data Model], nodes have identity. Node identity follows from the unique location of the node within exactly one XML document (or document fragment, in the case of XML being constructed within the [expression/query] itself). It is possible for two expressions to return not only the same value, but also the identical node. On the other hand, two expressions could return results with the same document structure, but different identities. [XPath/XQuery] supports comparison of nodes using either "node equality" (equality by identity) or "value equality" (equality by value), for instance by using the operators is or =.

Atomic values do not have an associated identity and are therefore always compared by value.

The difference between node equality and value equality is illustrated by the following example:

   let $a1 := <book><author>Suciu</author></book>,
       $a2 := <author>Suciu</author>,
       $a3 := $a1/author
   return
       ($a1/author is $a3), {-- true, they refer to the same node --}
       ($a1/author = $a2),  {-- true, they have the same value --}
       ($a1/author is $a2)  {-- false, they are not the same node --}

All [XPath/XQuery]'s operators preserve node identity with the exception of explicit copy operations, node (element, attribute, etc.) constructors and validate expressions. An element constructor always creates a deep copy of its attributes and child nodes. Other operators, such as sequence constructors or path expressions, do not result in copies of the corresponding nodes. So, for example, ($a3, $a2) creates a new sequence of nodes, the first of which has the same identity as $a1/author.

2.3.3 Document order and sequence order

There are two kinds of order in [XPath/XQuery]: sequence order and document order.

Sequence order. Sequences of items in the [XPath/XQuery] data model are ordered. Sequence order refers to the order of items within a given sequence.

Document order. Document order refers to the total order among all nodes in a given document. It is defined as the order of appearance of the nodes when performing a pre-order, depth-first traversal of a tree. For elements, this corresponds to the order of appearance of their opening tags in the corresponding XML serialization. Document order is equivalent to the definition used in [XML Path Language (XPath) : Version 1.0].

Depending on the context, it may be possible to talk about two different notions of order for the same (set of) nodes. For example:

   let $e := <list>
               <item id="1"/>
               <item id="2"/>
             </list>,
       $s := ($e/item[@id='2'], $e/item[@id='1'])
   ...

The item "1" is before item "2" in document order, but the same two nodes are in the opposite order in the sequence $s.

The order between nodes from distinct documents is implementation defined but must be stable. That is, it must not change for the duration of query evaluation.

2.3.4 Type annotations and anonymous types

A type annotation indicates the type name for each element and attribute node, which results from the validation process or is assigned by default (depending on the way the data was built).

For example, consider the document fragment

  <fact>The cat weighs <weight>12</weight> pounds.</fact>

and its associated schema

  <xs:element name="fact" type="FactType"/>

  <xs:complexType name="FactType" mixed="true">
    <xs:sequence>
      <xs:element name="weight" type="xs:integer">
    </xs:sequence>
  </xs:complexType>

Before validation, the two elements fact and weight in the document are annotated by xs:anyType.

After validation, the element fact is annotated with the type name FactType and the element weight is annotated with the type name xs:integer.

In the case a schema type does not have an explicit name, it is called of anonymous types. In that case, the data model annotates the corresponding element or attributes with an implementation-defined type name. Those special anonymous type names, are not visible to the user.

For example, the above schema could be written as an anonymous type as follows.

and its associated schema

  <xs:element name="fact">
    <xs:complexType mixed="true">
      <xs:sequence>
        <xs:element name="weight" type="xs:integer">
      </xs:sequence>
    </xs:complexType>
  </xs:element>

In that case, a type name is automatically generated by the system, this name is used to annotated the fact elements after schema validation.

Type annotations are have an impact on the semantics of [XPath/XQuery]. For example, consider the following function declaration

  define function convert_weight($x as element of type FactType)
    { ... }

This function only accepts as input an element annotated with the type FactType, or with one of the types derived from it. Therefore, the previous document fragment is only accepted by the function after it has been validated against the given schema.

[3 The XQuery type system] gives a formal description of data model values with type annotations and explain how type annotations are taken into account when matching a value against a given type.

2.4 Schemas and types

This section presents an introduction to (statically) typed languages in general, and a conceptual overview of the [XPath/XQuery] type system in particular. The [XPath/XQuery] type system is discussed formally in [3 The XQuery type system].

2.4.1 The elements of a (statically) typed language

A type system relates values, types, and expressions in the language.

The main constituent parts of a typed system are:

  • A universe of possible types. Type are composed of other types, starting with primitive types, and can be built using type constructors.

    In [XPath/XQuery], the primitive types are the primitive atomic types of [XML Schema Part 2]. Type constructors are also based on schema, and can be used to build types for attributes and elements, sequence and choice groups, etc. The [XPath/XQuery] type system is defined in [3.2 Types].

  • A notation for specifying types.

    In [XPath/XQuery], types are imported from XML Schema, and can be used in expressions using the SequenceType syntax. In order to model and reason about types in [XPath/XQuery], this document introduces its own notation for types. This notation is defined in [3.2 Types].

  • A relationship between values and types. Formally, the semantics of a type is defined to be the (usually infinite) set of instance values which match that type.

    For example, the type xs:integer consists of the set of all integer values, and the type element address { xs:string } consists of all elements named "address" whose contents are a single string value, etc.

    Matching a [XPath/XQuery] value against a type is defined in [3.4 Judgments for type matching].

  • A notion of subtyping. Subtyping is a relationship between types that plays an important role in a statically typed language. Notably, it is used to determine whether function calls are legal or not.

    Subtyping in [XPath/XQuery] is defined in [3.4.3 Subtype].

For a statically typed language one also needs to define:

  • Rules that relate expressions to types. Static type analysis infers a type for each expression in the language. The most important property for a static type system is that the type inferred statically must be such that for all valid inputs, evaluating the expression returns a result that matches the inferred type. If this property holds, then the static typing provides guarantees that certain kinds of errors can not occur at run-time.

    The static typing rules for [XPath/XQuery] are defined for all [XPath/XQuery] expressions in [5 Expressions], [6 The Query Prolog] and [7 Additional Semantics of Functions].

Finally, types can also be used during language evaluation if the language provides:

  • Expressions on types. A language can support operations that take types into account, such as casting, type matching, etc.

    [XPath/XQuery] provide several such expressions: "typeswitch", "cast as", "treat as", and "validate as". [XPath/XQuery] also support a "validate" expression, which performs XML Schema validation. Validation is related to matching in that if validation succeeds, it returns a value which matches the type used for validation. Expressions on types are defined in [5.12 Expressions on SequenceTypes]. The validate expression is defined in [3.8 Judgments for the validate expression].

The remainder of the section is devoted to several related features that merit special attention: the relationship between the [XPath/XQuery] type system and XML Schema, structural and named typing, and subtyping.

2.4.2 XML Schema and the XQuery type system

The [XPath/XQuery] type system is based on [XML Schema]. An introduction to XML Schema can be found in [XML Schema Part 0].

The [XPath/XQuery] type system captures a large subset of XML Schema. This section gives a summary of which features are captured and in some cases deviations from XML Schema.

The following components and features of XML Schema are captured exactly in the [XPath/XQuery] type system:

  • Element and attribute declarations;

  • Simple and complex type definitions;

  • Local attributes and elements;

  • Named and anonymous types;

  • the type name hierarchy;

  • Sequence, choice and all groups;

  • Wildcards;

  • Derivation by extension, list and union;

  • Substitution groups.

The following components or features of XML Schema are not represented in the [XPath/XQuery] type system.

  • Simple type facets;

  • Identity-constraint definitions;

  • Notations and annotations.

The following components or features of XML Schema are represented partially or differently in the [XPath/XQuery] type system.

  • The [XPath/XQuery] type system only captures an approximation of minOccurs and maxOccurs. Like DTDs, the [XPath/XQuery] type system only supports *, +, and ? which correspond to [minOccurs="0" maxOccurs="unbounded"], [minOccurs="1" maxOccurs="unbounded"], and [minOccurs="0" maxOccurs="1"] respectively.

  • The [XPath/XQuery] type system generalizes the notion of derivation by restriction for the needs of static type analysis. Derivation by restriction in XML Schema relies on a syntactic relationship between content models. The [XPath/XQuery] type system uses a generalization of this relationship based on the notion of inclusion between types -- also called structural subtyping.

At compile time, the [XPath/XQuery] environment imports XML Schema declarations, and loads them as declarations in the [XPath/XQuery] type system. This loading process is specified by a mapping from XML Schema to the [XPath/XQuery] type system, given in [8 Importing Schemas].

2.4.3 Structural and named typing

XML Schema is a powerful schema language for XML. XML Schema can describe both structural constraints as well as type annotations that apply to XML documents. These aspects are referred to as structural typing and named typing respectively.

  • Structural typing. An important notion underlying XML Schema is the concept of regular expressions, and their tree counterparts, regular tree grammars. An introduction to regular (tree) languages can be found in [Languages] or in [TATA].

    Tree grammars can be used to capture the structural constraints imposed by an XML Schema. Automata are the traditional way of implementing tree grammars and can be used to implement part of the XML Schema validation process.

    For instance, consider the following element declaration:

      <xs:element name="root">
        <xs:complexType>
          <xs:sequence maxOccurs="unbounded">
    	<xs:choice minOccurs="0" maxOccurs="unbounded">
    	  <xs:element ref="a"/>
    	  <xs:element ref="b" minOccurs="0"/>
    	</xs:choice>
    	<xs:element ref="c"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
    

    The structural constraints imposed by the definition of the content of element root can be described by the following regular expression (written here in DTD notation): ((a|b?)*,c)+. Such a constraint can be checked using a finite state automaton applied on the children of the element root in the instance document.

  • Named typing. In addition, XML Schema provides the ability to associate names with type definitions and to declare relationships between type names.

    For instance, consider the following two element declarations:

      <xs:element name="person" type="Person"/>
    
      <xs:complexType name="Person">
        <xs:sequence>
          <xs:element ref="ssn">
          <xs:choice>
            <xs:sequence>
              <xs:element ref="major" minOccurs="0"/>
              <xs:element ref="minors" maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:element ref="job_desc"/>
          </xs:choice>
        </xs:sequence>
      </xs:complexType>
    
      <xs:element name="student" type="Student"/>
    
      <xs:complexType name="Student">
        <xs:complexContent>
          <xs:restriction base="Person">
            <xs:sequence>
              <xs:element ref="ssn">
              <xs:element ref="major" minOccurs="0"/>
              <xs:element ref="minors" maxOccurs="unbounded"/>
            </xs:sequence>
          </xs:restriction>
        </xs:complexType>
      </xs:complexContent>
    

    The type Studentof the element student is derived by restriction from the type Person. Such a declaration not only defines a new type, but also creates a relationship between the type names Person and Student which needs to be taken into account when doing validation and matching against a given type. For instance, the following function

      define function salary($x as element of type Person)
        { .... }
    

    accepts as parameters elements of type Person as well as elements with types derived by restriction from Person, but does not accept elements with the same content model as the element person but a type which does not derive from the type Person.

2.4.4 Subtyping

A type is a subtype of another type if every value matching the first type also matches the second type. Since matching takes both type structure and type names into account, so is subtyping.

Here is a simple example of subtyping on two regular expressions:

  ( xs:double )*
  ( xs:integer | xs:double )*

The first type is a subtype of the second, because any sequence that contains only doubles is also an example of a sequence that contains either integers or doubles. This example only illustrates the structural subtyping.

Type1 <: Type2 indicates that type Type1 is a subtype of Type2. Note that the notation <: is used when defining the [XPath/XQuery] semantics, but is not part of the [XPath/XQuery] syntax.

2.4.4.1 Type substitutability

Subtyping plays a crucial role in the semantics of function application since all functions have an associated signature that declares the types of input parameters and the type of the result of the function.

Intuitively, one can call a function not only by passing an argument of the declared type, but also any argument whose type is a subtype of the declared type. This property is called type substitutability.

Ed. Note: [Kristoffer/XSL] Type substitutability should really be true for any subexpression, not just function arguments (it just happens that in functional languages, where type substitutability is usually defined, the situations are equivalent). Specifically type substitutability does not apply to any subexpression of [XPath/XQuery]: typeswitch violates it. In particular this means that while one may replace a function argument with one whose type is a subtype this does not guarantee that the resulting value is the same even if the value is the same (but cast to a subtype).

2.4.4.2 Subtyping and XML Schema derivation

Subtyping in [XPath/XQuery] is related to, but not identical to, "derivation by restriction" in XML Schema. A type derived by restriction is always a subtype of its base type, but the opposite is not true. For instance, consider the following types:

  ( xs:double )+
  xs:double, ( xs:integer | xs:double )*

The first type is a subtype of the second, because any sequence that contains one or more doubles is also an example of a sequence containing a double followed by a sequence of zero or more integers or doubles. But the first type cannot be derived from the second type using derivation by restriction as defined in XML Schema.

2.5 Functions

2.5.1 Functions and operators

The [XQuery 1.0 and XPath 2.0 Functions and Operators] document provides a number of useful basic functions over the components of the [XPath/XQuery] data model (atomic values, nodes, sequences, etc). A number of these functions are used in the course of describing the [XPath/XQuery] semantics. Here is the list of functions from the [XQuery 1.0 and XPath 2.0 Functions and Operators] document that are used in the [XPath/XQuery] Formal Semantics:

  • op:numeric-add
  • op:numeric-subtract
  • op:numeric-multiply
  • op:numeric-divide
  • op:numeric-mod
  • op:numeric-unary-plus
  • op:numeric-unary-minus
  • op:numeric-equal
  • op:numeric-less-than
  • op:numeric-greater-than
  • op:boolean-equal
  • op:boolean-less-than
  • op:boolean-greater-than
  • op:yearMonthDuration-equal
  • op:yearMonthDuration-less-than
  • op:yearMonthDuration-greater-than
  • op:dayTimeDuration-equal
  • op:dayTimeDuration-less-than
  • op:dayTimeDuration-greater-than
  • op:dateTime-equal
  • op:dateTime-less-than
  • op:dateTime-greater-than
  • op:add-yearMonthDurations
  • op:subtract-yearMonthDurations
  • op:multiply-yearMonthDuration
  • op:divide-yearMonthDuration
  • op:add-dayTimeDurations
  • op:subtract-dayTimeDurations
  • op:multiply-dayTimeDuration
  • op:divide-dayTimeDuration
  • op:add-yearMonthDuration-to-dateTime
  • op:add-dayTimeDuration-to-dateTime
  • op:subtract-yearMonthDuration-from-dateTime
  • op:subtract-dayTimeDuration-from-dateTime
  • op:add-yearMonthDuration-to-date
  • op:add-dayTimeDuration-to-date
  • op:subtract-yearMonthDuration-from-date
  • op:subtract-dayTimeDuration-from-date
  • op:add-dayTimeDuration-to-time
  • op:subtract-dayTimeDuration-from-time
  • op:QName-equal
  • op:anyURI-equal
  • op:hex-binary-equal
  • op:base64-binary-equal
  • op:NOTATION-equal
  • op:node-equal
  • op:node-before
  • op:node-after
  • op:node-precedes
  • op:node-follows
  • op:to
  • op:concatenate
  • op:item-at
  • op:union
  • op:intersect
  • op:except
  • op:operation
  • fn:false
  • fn:true
  • fn:count
  • fn:boolean
  • fn:get-namespace-uri
  • fn:get-local-name
  • fn:round
  • fn:compare
  • fn:not
  • fn:empty
  • fn:root
  • fn:error

2.5.2 Functions and static typing

Many functions in the [XQuery 1.0 and XPath 2.0 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:distinct-nodes function removes duplicates in any sequence of nodes. As a result, the signature given in the [XQuery 1.0 and XPath 2.0 Functions and Operators] document is also generic. For instance, the signature of the fn:distinct-nodes function is:

  fn:distinct-nodes(node*) as node*

If applied as is, this signature would result in poor static type information. In general, it would be preferable if some of these function signatures could take the type of input parameters into account. For instance, if the function fn:distinct-nodes is applied on a parameter of type element a*, element b, one can easily deduce that the resulting sequence is a collection of either a or b elements.

In order to provide better static typing, some specific typing rules are specified for some of the functions in [XQuery 1.0 and XPath 2.0 Functions and Operators]. These additional typing rules are given in [7 Additional Semantics of Functions]. Here is the list of functions that are given specific typing rules.

  • fn:error
  • fn:distinct-nodes
  • fn:distinct-values
  • op:union
  • op:intersect
  • op:except
  • op:to
  • fn:data

Ed. Note: There might be other functions that need specific typing rules. See [Issue-0135:  Semantics of special functions].

2.5.3 The error function

Some queries result in an error. Errors that are detected at compile-time, like parse errors or type errors, are reported to the user by the system. Dynamic errors are raised using the fn:error() function. General handling of errors in the Formal Semantics is still an open issue (See [Issue-0094:  Static type errors and warnings], [Issue-0098:  Implementation of and conformance levels for static type checking], [Issue-0171:  Raising errors], and [Issue-0169:  Conformance Levels]).

2.5.4 Data Model Accessors

Here is a list of data model constructors or accessors used for Formal Semantics specification.

  • dm:atomic-value
  • dm:children
  • dm:attributes
  • dm:parent
  • dm:name
  • dm:node-kind
  • dm:dereference
  • dm:empty-sequence
  • dm:namespaces
  • dm:type
  • dm:typed-value
  • dm:attribute-node-atomic
  • dm:element-node-atomic
  • dm:text-node

2.5.5 Other Formal Semantics functions

Here is a list of additional functions used for Formal Semantics specification.

  • fs:characters-to-string
  • fs:distinct-doc-order
  • fs:item-sequence-to-node-sequence
  • fs:item-sequence-to-string

2.6 Notations

In order to make the specification of the semantics both concise and precise, formal notations in the form of judgments and inference rules are used. This section, introduces the notations for judgments, inference rules and mapping rules, as well as the notion of an environment.

This section is intended for the reader who may not be familiar with these notations. The reader familiar with these notations can skip this section and go directly to [2.7 The Formal Semantics].

2.6.1 Grammar productions

Grammar productions are used in this document 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.

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

[28 (XQuery)]   FLWRExpr   ::=   ((ForClause |  LetClause)+ WhereClause? OrderByClause? "return")* QuantifiedExpr

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

[25 (XPath)]   ForExpr   ::=   (SimpleForClause "return")* QuantifiedExpr

XQuery Core grammar productions describe the XQuery Core. The complete XQuery Core grammar is given in [A Normalized core grammar]. XQuery Core productions are identified by a number, which corresponds to the number in [A Normalized core grammar], and are annotated by "(Core)". For instance, the following production describes the simpler form of "for" expressions present in the XQuery Core.

[23 (Core)]   ForExpr   ::=   (ForClause OrderByClause? "return")* TypeswitchExpr

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

[37 (Formal)]   Definition   ::=   (<"define" "element"> ElementName Substitution? Nillable? TypeReference)
|  (<"define" "attribute"> AttributeName TypeReference)
|  (<"define" "type"> TypeName TypeDerivation)

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

2.6.2 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

Painting is beautiful

holds if the painting Painting is beautiful.

Or more relevant, here are two example of judgments that are used extensively in the rest of this document.

Notation

The judgment

Expr => Value

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

Notation

The judgment

Expr : Type

holds when the expression Expr has type Type.

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 can be used to represent any [XPath/XQuery] expression, Value can be used to represent 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), which simply name 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. On the contrary, '$x+0 => 3' is an instance of the judgment 'Expr1 => Expr2'.

In a few cases, patterns may have a name which is not exactly the name of a grammar production but is based on it. For instance, a BaseTypeName is a pattern which 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.

2.6.3 Inference rules

Whether a judgments holds or not is specified by means of inference rules. Inference rules express the logical relation between judgments and describe how complex judgments can be concluded from simpler premise judgments. (As explained in [2.1 Processing model], this approach lends itself well to bottom-up algorithms.)

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

premise1 ... premisen

conclusion

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 must also hold.

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

$x => 0      3 => 3

$x + 3 => 3

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'.

It is also possible for an inference rule to have no premises above the line to have no judgments at all; this simply means that the expression below the line always holds:


3 => 3

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. For example, here is a rule that says that for any variable Variable that yields the integer value Integer, adding '0' yields the same integer value:

Variable => Integer

Variable + 0 => Integer

As in a judgment, each 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 more precise "what Variable is instantiated to in (this particular instantiation of) the inference rule".

2.6.4 Environments

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" statement can be captured in an environment and used for further evaluations.

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 either access existing information from an environment, or update the environment.

If "env" is an environment, then "env(symbol)" denotes the "object" to which symbol is mapped to. The notation is intentionally akin to function application as an environment can be seen as a "function" from the argument symbol to the "object" that the symbol is mapped to.

This specification uses environment groups that group related environments. If "env" is an environment group with the member "mem", then that environment is denoted "env.mem" and the value that it maps symbol to is denoted "env.mem(symbol)".

Updating is only defined on environment groups:

  • "env [ mem(symbol |-> object) ]" denotes the a new environment group which is identical to env except that the mem environment has been updated to map symbol to object. The notation symbol |-> object indicates that symbol is mapped to object in the new environment.

  • If the "object" is a type then the following conventional variant notation is used: "env [ mem(symbol : object) ]".

  • The following shorthand is also allowed: "env [ mem( symbol1 |-> object1 ; ... ; symboln |-> objectn ) ]" in which each symbol is mapped to a corresponding object in the new environment.

    This notation is equivalent to nested simple updates, as in " (...(env[mem(symbol1 |-> object1)]) ... [mem(symboln |-> objectn)])".

Note that updating the environment overrides any previous binding that might exist for the same name. Updating the environment is used to capture the scope of variables, namespaces, etc. Also, note that there are no operations to remove entries from environments: the need never arises because the environment group from "before" the update remains accessible concurrently with the updated version.

Environments are typically used as part of a judgment, to capture some of the context in which the judgment is computed. Indeed, 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 ubiquitous in inference rules.

For instance, the judgment

dynEnv |- Expr => Value

should be read: assuming the dynamic environment dynEnv, the expression Expr yields the value Value.

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

2.6.5 Putting it together

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

statEnv |- Expr1 : Type1      statEnv |- Expr2 : Type2

statEnv |- Expr1 , Expr2 : Type1, Type2

This rule is read as follows: if two expressions Expr1 and Expr2 have already been statically inferred to have 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 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/return" expression. The binding of the new variable is captured by an update to the varType component of the original static environment.

statEnv |- Expr1 : Type1      statEnv [ varType(QName : Type1) ] |- Expr2 : Type2

statEnv |- let $QName := Expr1 return Expr2 : Type2

This rule should be read as follows. First, the type Type1 for the "let" input expression Expr1 is computed. Second the "let" variable is added into the varType member of the static environment group statEnv, with type Type1. Finally, the type Type2 of Expr2 is computed in that new environment.

Ed. Note: Jonathan suggests that we should explain 'chain' inference rules. I.e., how several inference rules are applied recursively.

2.7 The Formal Semantics

Finally, this section introduces the top-level notations defining the processing model phases described above. These notations are used to define the normalization, static type analysis, and dynamic evaluation processing phases.

2.7.1 Normalization

Normalization is specified using mapping rules which describe how a [XPath/XQuery] expression is rewritten into another expression in the [XPath/XQuery] Core. Note that mapping rules are also used in [8 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
==
Mapped Object

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

(Since normalization is always done in the context of the static context the above is really a shorthand for

statEnv |- [Object] Subscript == Mapped Object

but we shall stay with the shorthand because statEnv will always be implied.)

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

Ed. Note: [Kristoffer/XSL] We should decide whether to use a shorthand notation as suggested or modify the mapping rules throughout.

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

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
        return
          element pair { ($i,$j) }

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

2.7.2 Static type inference

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

Notation

The judgment

statEnv |- Expr : Type

holds when, assuming the static environment statEnv is given, the expression Expr has type Type.

Example

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

For instance, the following expression.

   let $v := 3
   return
       $v+5

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

Note

The type of an expression is computed by inference. Static type inference rules are given to describe, 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 of such a rule:

statEnv |- Expr1 : xs:boolean      statEnv |- Expr2 : Type2      statEnv |- Expr3 : Type3

statEnv |- if Expr1 then Expr2 else Expr3 : ( Type2 | Type3 )

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 choice: '(Type2|Type3)'.

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

2.7.3 Dynamic Evaluation

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

Notation

The judgment

statEnv ; dynEnv |- Expr => Value

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

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

Example

For instance, the following expression.

   let $v := 3
   return
       $v+5

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

Note

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

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

2.7.4 Formal Semantics internal links

Note that for convenience, the formal semantics features internal hyperlinks to be able to recall of the judgments and environments being used in inference rules. Clicking on a judgment or environment should point to the location where that judgment or environment has been defined.

3 The XQuery type system

The [XPath/XQuery] type system is used for the specification of both the dynamic and the static semantics of [XPath/XQuery]. It is used to describe the semantics of expressions on sequence types and in type conversion rules. It is also the basis for the static semantics of [XPath/XQuery].

3.1 Values

This section introduces formal notations for describing XQuery values. Those notations are used extensively to describe and manipulate values in the inference rules. The formal notations for values introduced here are not exposed to the XQuery user.

A value is a sequence of zero or more items. An item is either a node or an atomic value. A node is either an element, an attribute, a document node, or a text node. Text nodes always contain string values of type xs:anySimpleType. Elements, attributes, and atomic values have a type annotation.

A atomic value encapsulates an XML Schema atomic type (which is its type annotation) and a corresponding value of that type. An XML Schema atomic type [XML Schema Part 2] may be primitive or derived, or xs:anySimpleType. The corresponding atomic type value may be a value in the value space of one of the 19 primitive XML Schema types.

Type annotations are always present. A type annotation can be either the QName of a declared type, or an anonymous type. Anonymous types corresponds to XML Schema types for which the user did not write an explicit names. Those type names are not visible to the user, but are generated during schema validation and used as an annotation in the data model. In the Formal Semantics, we write those type names with a a special notation: [Anon0], [Anon1], etc.

Untyped elements (e.g., in from well-formed documents) are annotated with xs:anyType, untyped attributes are annotated with xs:anySimpleType, and untyped atomic values (i.e., text content or attribute content in well-formed documents) are annotated with xs:anySimpleType.

A value is called a simple value if it consists of a sequence of zero or more atomic values.

[7 (Formal)]   Value   ::=   Item
|  (Value "," Value)
|  ("(" ")")
[8 (Formal)]   SimpleValue   ::=   AtomicValue
|  (SimpleValue "," SimpleValue)
|  ("(" ")")
[9 (Formal)]   ElementValue   ::=   "element" ElementName TypeAnnotation "{" Value "}"
[10 (Formal)]   AttributeValue   ::=   "attribute" AttributeName TypeAnnotation "{" SimpleValue "}"
[11 (Formal)]   DocumentValue   ::=   "document" "{" Value "}"
[12 (Formal)]   TextValue   ::=   "text" "{" String "}"
[13 (Formal)]   NodeValue   ::=   ElementValue
|  AttributeValue
|  DocumentValue
|  TextValue
[14 (Formal)]   Item   ::=   NodeValue
|  AtomicValue
[15 (Formal)]   AtomicValue   ::=   AtomicTypeValue TypeAnnotation
[16 (Formal)]   AtomicTypeValue   ::=   String
|  Boolean
|  Decimal
|  Float
|  Double
|  Duration
|  DateTime
|  Time
|  Date
|  GYearMonth
|  GYear
|  GMonthDay
|  GDay
|  GMonth
|  HexBinary
|  Base64Binary
|  AnyURI
|  QName
|  NOTATION
[17 (Formal)]   TypeAnnotation   ::=   <"of" "type"> TypeName
[18 (Formal)]   ElementName   ::=   QName
[21 (Formal)]   AttributeName   ::=   QName
[25 (Formal)]   TypeName   ::=   QName |  AnonymousTypeName
[24 (Formal)]   AnonymousTypeName   ::=   [Anon1] |  [Anon2]

Notation

In the above grammar, the atomic type names are used to represents the value space of the corresponding XML Schema atomic type. For instance, "String" indicates the value space of xs:string, and "Decimal" indicates the value space of xs:decimal.

Note that the same rule about constructing sequences apply to the values described by that grammar. Notably sequences cannot be nested. For example, the sequence (10, (1, 2), (), (3, 4)) is equivalent to the sequence (10, 1, 2, 3, 4).

Ed. Note: Issue: The formal semantics does not represent comments and process-instructions (See [Issue-0143:  Support for PI, comment and namespace nodes]).

Ed. Note: Issue: This formal notation for values only represents either text nodes or values. (See [Issue-0144:  Representation of text nodes in formal values])

Examples

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:anyType {
    text { "The cat weighs " },
    element weight of type xs:anyType {
      attribute units of type xs:anySimpleType {
        "lbs" of type xs:anySimpleType
      }
      text { "12" }
    },
    text { " pounds." }
  }

A document before and after validation.

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

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

  element weight of type xs:anyType {
    attribute xsi:type of type xs:anySimpleType {
      "xs:integer" of type xs:anySimpleType
    },
    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
  }

Note that XML Schema permits attributes with name xsi:type and xsi:nil to appear on any element.

An element with a list type

  <sizes>1 2 3</sizes>

Before validation, this element is represented as:

  element sizes of type xs:anyType {
    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:anyType {
    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 [Anon1] {
    1 of type xs:integer,
    2 of type xs:integer,
    3 of type xs:integer
  }

where [Anon1] stands for the internal anonymous name generated by the system for the sizes element.

An element with a union type

  <sizes>1 two 3 four</sizes>

Before validation, this element is represented as:

  element sizes of type xs:anyType {
    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
  }

3.2 Types

This section introduces formal notations for describing XQuery types. Those notations are used extensively to describe and manipulate types in the inference rules. The formal notations for types introduced here are not exposed to the XQuery user.

3.2.1 Item types

An item type is either an atomic type, an element type, an attribute type, a document node type, a text node type, or the untyped type (i.e., which is the type of untyped text values).

[28 (Formal)]   ItemType   ::=   AtomicTypeName
|  ElementType
|  AttributeType
|  "document"
|  "text"
|  "untyped"
[29 (Formal)]   AtomicTypeName   ::=   QName
[30 (Formal)]   ElementType   ::=   "element" ElementName? Nillable? TypeReference?
[31 (Formal)]   AttributeType   ::=   "attribute" AttributeName? TypeReference?
[32 (Formal)]   Nillable   ::=   "nillable"
[34 (Formal)]   TypeReference   ::=   <"of" "type"> TypeName

An element or attribute type has an optional name and an optional type reference. A name alone corresponds to 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 any element or any attribute. In addition, an element type have an optional nillable flag which indicates whether the element can be nilled or not.

Examples

A text node type

  text

matches any text node, such as:

  text { "Text is beautiful" }

A wildcard element

  element

matches any element.

A wildcard element of type string

  element of type xs:integer 

matches any element of type string, such as:

  element name of type xs:string { "John Doe" }

A nillable element of type string

  element size nillable of type xs:integer 

matches any element with name size of type xs:integer, such as:

  element size of type xs:integer {
    2 of type xs:integer
  }

or it matches any element with name size which has no content and the xsi:nil attribute set to true, such as:

  element size of type xs:integer {
    attribute xsi:nil of type xs:anySimpleType { "true" }
  }

A reference to a globally declared attribute

  attribute sizes

refers to the global declaration for the attribute sizes.

An element with an anonymous type

  element sizes of type [Anon1]

matches any element with name sizes and the anonymous type [Anon1], such as:

  element sizes of type [Anon1] {
    1 of type xs:integer,
    2 of type xs:integer,
    3 of type xs:integer
  }

3.2.2 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, or empty choice (written none).

The type none matches no values. It is called the empty choice because it is the identity for choice, that is (Type | none) = Type)). The type none appears in the definition of prime types in [3.6 Judgments for the typeswitch expression], and is the static type for [2.5.3 The error function].

[26 (Formal)]   Type   ::=   ItemType
|  (Type Occurrence)
|  (Type "&" Type)
|  (Type "," Type)
|  (Type "|" Type)
|  ("(" ")")
|  "none"
[27 (Formal)]   Occurrence   ::=   "*" |  "+" |  "?"

The type system includes three binary operators on types: ",", "|" and "&", corresponding respectively to sequence, choice and all groups in Schema. The 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 is used to represent all groups in XML Schema. All group in XML Schema are restricted to apply only on global or local element declarations with lower bound 0 or 1, and upper bound 1.

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.

A choice between two elements

The "|" operator builds a "choice" between 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 gobal 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.

  ()

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

3.2.3 Top level definitions

At the top level, one can define elements, attributes, and types.

[37 (Formal)]   Definition   ::=   (<"define" "element"> ElementName Substitution? Nillable? TypeReference)
|  (<"define" "attribute"> AttributeName TypeReference)
|  (<"define" "type"> TypeName TypeDerivation)
[38 (Formal)]   Substitution   ::=   <"substitutes" "for"> ElementName
[33 (Formal)]   TypeDerivation   ::=   Derivation? Mixed? "{" Type? "}"
[35 (Formal)]   Derivation   ::=   ("restricts" TypeName)
|  ("extends" TypeName)
[36 (Formal)]   Mixed   ::=   "mixed"

A type definition has a name (possibly anonymous) and a type derivation. A type derivation indicates if the type is derived by extension or restriction from its based type, gives its content model, and an optional flag indicating if it has mixed content.

A type is derived either by extension or restriction from a base type. In case the type derivation is omitted, the type derives by restriction from xs:anyType, as in:

  define type Bib { xs:integer } =
  define type Bib restricts xs:anyType { xs:integer }

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

  define type Bib { } =
  define type Bib { () }

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

Examples

A type declaration with complex content

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

A type declaration with complex content derived by extension

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

A type declaration with mixed content

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

A type declaration with simple content derived by restriction

  define type SKU restricts xsd:string { xsd:string }

An element declaration

  define element address of type Address

An element declaration with a substitution group

  define element usaddress substitutes for address of type USAddress

An element declaration which is nillable

  define element zip nillable of type xs:integer

3.2.4 Built-in type declarations

The following type definitions capture the primitive types from Schema.

  define type xs:string restricts xs:anySimpleType { xs:string }
  define type xs:decimal restricts xs:anySimpleType { xs:decimal }
  ...

In the above definitions, each name (such as xs:string) appears twice. The first appearance declares the relation between type names (xs:string is derived by restriction from xs:anySimpleType). The second declares the value space for the type (the value space of xs:string is described by xs:string, and corresponds to the value space as defined in the XML Schema specification).

The following type definition captures the Ur simple type from Schema.

  define type xs:anySimpleType restricts xs:anyType {
    ( xs:string | xs:decimal | ... )*
  }

The name of the Ur simple type is xs:anySimpleType. It is derived by restriction from xs:anyType, its content is given by the union of all primitive atomic types.

Note that there is no separate "value space" for the type untyped. It has the same value space as xs:string, but its type annotation is xs:anySimpleType. The following example shows the distinction between a value of type string containing "Database" and an untyped value containing "Database": both are using string values as content with different type annotations.

"Databases" of type xs:string
"Databases" of type xs:anySimpleType

The following type definition captures the Ur type from Schema.

  define type xs:anyType restricts xs:anyType {
    attribute*, ( xs:anySimpleType | ( element* & text* ) )
  }

The xs:anyType is defined by restriction from itself, and it can contain any number of attributes, and either a simple content or a complex content with any number of elements or text nodes.

3.2.5 Syntactic constraints on types

The type system given in [3.2 Types] gives a simple but overly general definition of types. For instance, the above type grammar allows types to describe sequences of attributes and elements in any order. For example, the following type, describing a sequence of zero or more elements or attributes with name "year", is allowed.

  (element year of type xs:string | attribute year of type xs:string)*

There are two reasons for this approach. First, it makes the grammar for types simpler. Second, it allows to describe types for heterogeneous sequences, that can result from [XPath/XQuery] expressions but cannot be represented as an XML Schema.

When constructing elements, or attributes, some additional constraints on type must to be checked, for which this grammar is too general. This section gives auxiliary grammar productions which impose additional constraints on the content of elements and attributes.

First, a grammar for simple types is defined. This grammar is a subset of the grammar for types. A simple type is composed from atomic types by optional, one or more, zero or more, choice, or empty choice.

[39 (Formal)]   SimpleType   ::=   AtomicTypeName
|  (SimpleType Occurrence)
|  (SimpleType "|" SimpleType)
|  ("(" ")")
|  "none"

An all group contains only attributes or only elements; attributes or elements in an all group may be optional but not repeated; attributes always precede other content of an element.

[40 (Formal)]   AttributeAll   ::=   AttributeType
|  (AttributeType "?")
|  (AttributeAll "&" AttributeAll)
|  ("(" ")")
[41 (Formal)]   ElementAll   ::=   ElementType
|  (ElementType "?")
|  (ElementAll "&" ElementAll)
|  ("(" ")")
|  "none"
[42 (Formal)]   ElementNoAll   ::=   ElementType
|  "text"
|  (ElementType Occurrence)
|  (ElementAll "," ElementAll)
|  (ElementAll "|" ElementAll)
|  ("(" ")")
[0 (Formal)]   ElementContent   ::=   "ElementContent"
[43 (Formal)]   ElementBody   ::=   AttributeAll "ElementContent"

The type in an element type should always match the grammar for ElementBody given above. (Note that in case the element type is omitted altogether, e.g., like in element a { }, the type is implicitely matching the empty sequence.)

Those auxiliary productions is be used when matching the type content of elements or attributes within inference rules.

3.2.6 Example

Here is a schema describing purchase orders, taken from the XML Schema Primer, followed by its mapping into the [XPath/XQuery] type system. The complete mapping from XML Schema into the [XPath/XQuery] type system is given in [8 Importing Schemas].

  <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>
  namespace xsd = "http://www.w3.org/2001/XMLSchema"

  define element purchaseOrder of type ipo: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 ipo: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 [Anon1]*
  }

  define type [Anon1] {
    element productName of type xsd:string,
    element quantity of type [Anon2],
    element USPrice of type xsd:decimal,
    element comment?,
    element shipDate of type xsd:date?
  }

  define type [Anon2] restricts xsd:positiveInteger { xsd:positiveInteger }

  define type SKU restrict xsd:string { xsd:string }

Note the way the two anonymous types inside the item element are handled by giving them anonymous names [Anon1] and [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 XQuery type system.

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

  <element name="appt"/>
    <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"/>

Those definitions are written in the type system as follows.

  define type NYCAddress extends USAddress {
    element appt
  }

  define element appt of type [Anon3]

  define type [Anon3] restricts xsd:positiveInteger

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

3.3 Judgments for name hierarchies

Introduction

Many static and dynamic inference rules need to operate on element, attributes and type names. This section defines several judgments on names used in the rest of the Formal Semantics.

The first two judgments are capturing the derivation hiearchy and the substitution group hierarchy. The we introduce judgments to compute the "most precise" name within those hierarchies.

3.3.1 Derives

Notation

The judgment

statEnv |- TypeName derives from TypeName

holds when the first type name derives from the second type name.

Example

For example, assuming the extended XML Schema given in section [3.2.6 Example], 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
  [Anon3]              derives from  xsd:positiveInteger
  [Anon3]              derives from  xsd:integer
  [Anon3]              derives from  xs:anySimpleType
  [Anon3]              derives from  xs:anyType

Note

Derivation is a partial order. It is reflexive and transitive by the definition below. It is asymmetric because no cycles are allowed in derivation by restriction or extension.

Semantics

This judgment is specified by the following rules.

Some rules have hypotheses that simply list a type, element, or attribute declaration.

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 restriction or extension.

statEnv.typeDefn(TypeName) => define type TypeName extends BaseTypeName Mixed? { Type? }

statEnv |- TypeName derives from BaseTypeName

statEnv.typeDefn(TypeName) => define type TypeName restricts BaseTypeName Mixed? { Type? }

statEnv |- TypeName derives from BaseTypeName

Derivation is transitive.

statEnv |- TypeName1 derives from TypeName2      statEnv |- TypeName2 derives from TypeName3

statEnv |- TypeName1 derives from TypeName3

3.3.2 Substitutes

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 the first element name substitutes for the second element name.

Example

For example, assuming the extended XML Schema given in section [3.2.6 Example], then the following judgments hold.

  usaddress  substitutes element for  address
  nyaddress  substitutes element for  usaddress
  nyaddress  substitutes element 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.elemDecl(ElementName) => define element ElementName substitutes for BaseElementName Nillable? TypeReference

statEnv |- ElementName substitutes for BaseElementName

Substitution is transitive.

statEnv |- ElementName1 substitutes for ElementName2      statEnv |- ElementName1 substitutes for ElementName3

statEnv |- ElementName1 substitutes for ElementName3

3.4 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 [2.4.2 SequenceType] in [XQuery 1.0: A Query Language for XML].

  • 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.

Type matching and subtyping need to lookup the name and type annotations for any attribute and element types. First, an auxiliary judgment to that effect is defined.

3.4.1 Element and attribute lookup

Element and attribute types can be of various kinds: reference to a global element or attribute declaration, local element with or without a wildcard, an element can be nillable or not, etc. The lookup judgments are used to obtain the appropriate type annotations from any given attribute or element type.

Notation

The judgment

statEnv |- ElementName lookup ElementType yields Nillable? TypeReference

holds when matching an element with the given element name against the given element type requires that the element be nillable as indicated and matches the type reference.

Example

For example, assuming the extended XML Schema given in section [3.2.6 Example], then the following judgments hold.

  comment    lookup element comment                          yields of type xsd:string
  size       lookup element size nillable of type xs:integer yields nillable of type xsd:string
  appt       lookup element appt                             yields of type [Anon3]
  nycaddress lookup element address                          yields of type NYCAddress

Note that in the case the element name is in the substitution group, the lookup returns the type name of 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 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 |- ElementName1 substitutes for ElementName2
statEnv.elemDecl(ElementName1) => define element ElementName1 Substitution? Nillable? TypeReference

statEnv |- ElementName1 lookup element ElementName2 yields Nillable? TypeReference

If the given element name matches the element name in the element type, and the element type contains a type reference, then lookup yields that type reference.


statEnv |- ElementName lookup element ElementName Nillable? TypeReference yields Nillable? TypeReference

If the element type has no element name but contains a type reference, then lookup yields the type reference.


statEnv |- ElementName lookup element TypeReference yields TypeReference

If the element type has no element name and no type reference, then lookup yields xs:anyType.


statEnv |- ElementName lookup element yields of type xs:anyType

Notation

The judgment

statEnv |- AttributeName 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 [3.2.6 Example], then the following judgments hold.

  orderDate  lookup  attribute orderDate of type xsd:date  yields  of type xsd:date?
  orderDate  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 lookup yields the type reference in the attribute declaration for the given attribute name.

statEnv.attrDecl(AttributeName) => define attribute AttributeName TypeReference

statEnv |- AttributeName 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 lookup yields that type reference.


statEnv |- AttributeName lookup attribute AttributeName TypeReference yields TypeReference

If the attribute type has no attribute name but contains a type reference, then lookup yields the type reference.


statEnv |- AttributeName lookup attribute TypeReference yields TypeReference

If the attribute type has no attribute name and no type reference, then lookup yields xs:anySimpleType.


statEnv |- AttributeName lookup attribute yields of type xs:anySimpleType

3.4.2 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 [3.2.6 Example], then the following judgments hold.

  element comment of type xsd:string { "This is not important" }
    matches
  element comment of type xsd:string

  (element appt of type [Anon3] { 2510 },
   element appt of type [Anon3] { 2511 })
    matches
  element appt+

  ()
    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 element against an element type.

An element matches an element type if the element type resolves to another element type, and the type annotation is derived from the type annotation of the resolved type. Note that there is no need to check structural constraints on the value since since those have been checked during XML Schema validation and the value is assumed to be consistent with its type annotation.

statEnv |- ElementName lookup ElementType yields Nillable? of type BaseTypeName
statEnv |- TypeName derives from BaseTypeName
Value filter @xsi:nil => () or false

statEnv |- element ElementName of type TypeName { Value } matches ElementType

In the case the element has been nilled, the following alternative rule applies, which checks that the type is nillable and that there exists and xsi:nil attribute set to true in the element.

statEnv |- ElementName 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.

statEnv |- AttributeName lookup AttributeType yields of type BaseTypeName
statEnv |- TypeName derives from BaseTypeName

statEnv |- attribute AttributeName of type TypeName { Value } matches AttributeType

A document node matches the corresponding document type.


statEnv |- document { Value } matches document

A text node matches text.


statEnv |- text { String } matches text

An atomic value matches an atomic type if its type annotation derives from the atomic type. The value itself is ignored -- this is checked as part of validation.

statEnv |- AtomicTypeName1 derives from AtomicTypeName2

statEnv |- AtomicValue of type AtomicTypeName1 matches

An atomic value matches "untyped" only if it is a string an is annotated with xs:anySimpleType.


statEnv |- String of type xs:anySimpleType matches untyped

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

If two values match two types, then their sequence matches the corresponding sequence type.

statEnv |- Value1 matches Type1
statEnv |- Value2 matches Type2

statEnv |- Value1,Value2 matches Type1,Type2

If a value matches a type, then it also matches a choice type where that type is one of the choices.

statEnv |- Value matches Type1

statEnv |- Value matches Type1|Type2

statEnv |- Value matches Type2

statEnv |- Value matches Type1|Type2

If two values match two types, then their interleaving matches the corresponding all group.

statEnv |- Value1 matches Type1
statEnv |- Value2 matches Type2
statEnv |- Value1 interleave Value2 yields Value

statEnv |- Value matches Type1 & Type2

An optional type matches a value of that type or the empty sequence.

statEnv |- Value matches (Type | ())

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 |- Value1 matches Type      statEnv |- Value2 matches Type*

statEnv |- Value1, Value2 matches Type*

statEnv |- Value1 matches Type      statEnv |- Value2 matches Type*

statEnv |- Value1, Value2 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 the literature. The interested reader can consult the relevant literature, for instance [Languages], or [TATA].

3.4.3 Subtype

Introduction

This section defines the semantics of subtyping in [XPath/XQuery]. Subtyping is used during the static type analysis, in typeswitch expressions, treat and assert expressions, and to check the correctness of function applications.

Notation

The judgment

statEnv |- Type1 <: Type2

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 Type1 holds, then Value matches Type2 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 |- Type1 <: Type2     

and,

statEnv |- Type2 <: Type3     

then,

statEnv |- Type1 <: Type3

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 type.

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

3.5 Judgments for sequences of item types

Introduction

Some [XPath/XQuery] operations work on sequences of items. For instance, [For/FLWOR] expressions iterate over a sequence of items, the fn:distinct function removes duplicates items in a sequence, the fn:unordered function can return all items in a sequence in any order, etc.

Static typing for those operations need to infer a type acceptable for all the items in the sequence. This sometimes require to approximate 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 will be bound to each element in the sequence. Since each item as a 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 occurrence 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.

In Section [5.8 [For/FLWOR] Expressions], we will see how static inference for this example finally results in the type, which is a sequence of one or more items of one of the item types in the input sequence.

    (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 section defines the notion of prime type which is a choice of item types. It defines two functions on type which compute the prime type of an arbitrary type, and approximate the occurrence of items in an arbitrary type. Those judgments are used notably in the static semantics of "for" expressions, "fn:unordered", and "fn:distinct" functions.

Notation

A choice of item types is called a prime type, as described by the following grammar production.

[44 (Formal)]   PrimeType   ::=   ItemType
|  (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 following auxiliary occurrence indicators are used: 1 for exactly one occurrence, and 0 for exactly zero occurrences, i.e., the occurrence indicator of the empty list.

Semantics

The prime function is defined by induction as follows.

prime(ItemType)  =  ItemType
prime(())  =  none
prime(none)  =  none
prime(Type1 , Type2)  =  prime(Type1) | prime(Type2)
prime(Type1 & Type2)  =  prime(Type1) | prime(Type2)
prime(Type1 | Type2)  =  prime(Type1) | prime(Type2)
prime(Type?)  =  prime(Type)
prime(Type*)  =  prime(Type)
prime(Type+)  =  prime(Type)

Semantics

The quantifier function is defined by induction as follows.

quantifier(ItemType)  =  1
quantifier(())  =  0
quantifier(none)  =  0
quantifier(Type1 , Type2)  =  quantifier(Type1) , quantifier(Type2)
quantifier(Type1 & Type2)  =  quantifier(Type1) , quantifier(Type2)
quantifier(Type1 | Type2)  =  quantifier(Type1) | quantifier(Type2)
quantifier(Type?)  =  quantifier(Type) · ?
quantifier(Type*)  =  quantifier(Type) · *
quantifier(Type+)  =  quantifier(Type) · +

This definition uses the sum (Occurrence1 , Occurrence2), the choice (Occurrence1 | Occurrence2), and the product (Occurrence1 · Occurrence2) of two occurrence indicators Occurrence1, Occurrence2, which are defined by the following tables.

 ,  0  1  ?  +  * 
 0  0  1  ?  +  * 
 1  1  +  +  +  + 
 ?  ?  +  *  +  * 
 +  +  +  +  +  + 
 *  *  +  *  +  * 
    
 |  0  1  ?  +  * 
 0  0  ?  ?  *  * 
 1  ?  1  ?  +  * 
 ?  ?  ?  ?  *  * 
 +  *  +  *  +  * 
 *  *  *  *  *  * 
    
 ·  0  1  ?  +  * 
 0  0  0  0  0  0 
 1  0  1  ?  +  * 
 ?  0  ?  ?  *  * 
 +  0  +  *  +  * 
 *  0  *  *  *  * 

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 | ())                     = 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 | ())                     = ?
  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 · 0  =  ()
Type · 1  =  Type
Type · ?  =  Type?
Type · +  =  Type+
Type · *  =  Type*

3.6 Judgments for the "typeswitch" expression

Introduction

Static type analysis for the "typeswitch" expression has to compute the choice of all the common items between two types, and the corresponding occurrence indicators.

Example

For example, consider the following typeswitch expression, applied on the result of the previous query.

    let $recipients := //shipTo return
      typeswitch ($recipients)
        case $r as element of type NYCAddress return
            <single-nyc-recipient> { $r/street, $r/appt } </single-nyc-recipient>
        case $r as element usaddress? return
            <single-us-recipient> { $r/city, $r/street } </single-us-recipient>
        default return
            <all-recipients> { $recipients } </all-recipients>

Static type analysis needs to compute the type of the variable $r precisely for the two first case clauses. This type depends on both the type for the input expression ($recipients) and the type of the case clause.

If the variable $recipients has type

  element nycaddress of type NYCAddress

then the first case branch is always evaluated and variable $r has type

  element nycaddress of type NYCAddress

Note that the type on the case clause was using a wildcard element name so the static typing for the typeswitch must take into account the element name from the type of the input expression.

If the variable $recipients has type

  element usaddress of type USAddress

then both the first and the second branch of the typeswitch can be evaluated. The type of the variable $r in the first branch must be an element type such that its element name smaller than both usaddress and the element wildcard name, and the type annotation is smaller than both USAddress and NYCAddress, which results in

  element usaddress of type NYCAddress

The type of variable $r in the second branch is the same as the type for the input expression, which is

  element usaddress of type USAddress

Note that since the input expression indicates that there is exactly one item, and the type in the case clause indicate an optional item, then the type of the variable $r is such that there is exactly one item, which is the conjunction of constraints from both occurrence indicators.

Notation

The two following auxiliary functions on types are defined.

The function common-prime(PrimeType1, PrimeType2) computes the type for all the items common between the prime types PrimeType1 and PrimeType2, and combines them into a new prime type.

The function common-occurrence(Occurrence1, Occurrence2) computes the occurrence indicator which approximates the possible number of items that can result from the constraints described by both Occurrence1, and Occurrence2.

Semantics

The common-prime function is defined by induction as follows.

The common-prime for two arbitrary prime types, is defined as the choice containing the results of the function common-prime applied between all possible pairs of items in each input prime types.

statEnv |- common-prime( ItemType1, ItemType1' ) = ItemType(1,1)
statEnv |- common-prime( ItemType1, ItemType2' ) = ItemType(1,2)
···
statEnv |- common-prime( ItemTypen, ItemTyper' ) = ItemType(n,r)

statEnv |- common-prime( ( ItemType1 | ··· | ItemTypen ), ( ItemType1' | ··· | ItemTyper' ) ) = ItemType(1,1) | ··· | ItemType(n,r)

The common-prime function between any pair of item types returns either a new item type or the empty choice (none);. Remember that since none is the identity for choice, all of those cases are eventually be eliminated through the rule above.

If one item type is a subtype of the other, the function returns the subtype.

statEnv |- ItemType1 <: ItemType2

statEnv |- common-prime(ItemType1, ItemType2) = ItemType1

statEnv |- ItemType2 <: ItemType1

statEnv |- common-prime(ItemType1, ItemType2) = ItemType2

This rule captures most of the cases, including cases with document, text nodes and atomic types.

In the case of attributes and elements, additional rules also apply to cover the cases where the element name and the type names are compatible but subtyping does not hold directly, which happens when one of the element or attribute type has a wildcard name.

If one element type has a wildcard name, then one applies the same rule with the wildcard replaced by the element name of the other element type.

statEnv |- common-prime(element ElementName2 of type TypeName1, element ElementName2 Nillable2? TypeReference2?) = ElementType3

statEnv |- common-prime(element of type TypeName1, element ElementName2 Nillable2? TypeReference2?) = ElementType3

statEnv |- common-prime(element ElementName1 Nillable1? TypeReference1?, element ElementName1 of type TypeName2) = ElementType3

statEnv |- common-prime(element ElementName1 Nillable1? TypeReference1?, element of type TypeName2) = ElementType3

If one attribute type has a wildcard name, then one applies the same rule with the wildcard replaced by the attribute name of the other attribute type.

statEnv |- common-prime(attribute AttributeName2 of type TypeName1, attribute AttributeName2 TypeReference2?) = AttributeType3

statEnv |- common-prime(attribute of type TypeName1, attribute AttributeName2 TypeReference2?) = AttributeType3

statEnv |- common-prime(attribute AttributeName1 TypeReference1?, attribute AttributeName1 of type TypeName2) = AttributeType3

statEnv |- common-prime(attribute TypeReference1?, attribute of type TypeName2) = AttributeType3

In all the other cases, common-prime returns none. I.e., otherwise:

statEnv |- common-prime(ItemType1, ItemType2) => none

Semantics

The common-occurrence function is defined by the following table.

 common-occurrence  0  1  ?  +  * 
 0  0  0  0  0  0 
 1  0  1  1  1  1 
 ?  0  1  ?  1  ? 
 +  0  1  1  +  + 
 *  0  1  ?  +  * 

Examples

For example, the following illustrates some applications of common-prime and common-occurrence.

  common-prime((element a),(element a))                                      = element a
  common-prime((element a),(element b))                                      = none
  common-prime((element a | element b | element c), (element c | element a)) = element a | element c

  common-occurrence(+,+)   = +
  common-occurrence(*,+)   = +
  common-occurrence(?,+)   = 1

Note that the last occurrence indicator should be '1', since the first input occurrence indicator '?' specifies that there should be at most one item, while the second '+' specifies that there should be at least one.

The definition of relies on subtyping, hence covering some non trivial cases with derivation, substitution groups, etc. For example, consider the following definitions.

  define element person of type Person

  define type Person { element name of type xs:string }

  define element student substitutes for person of type Student
  define type Student extends Person {
    element promotion of type Promotion,
    element grade of type Grade
  }

  define type Promotion restricts xs:integer { xs:integer }
  define type Grade restricts xs:integer { xs:integer }

The following illustrates some more advanced applications of common-prime and common-occurrence.

  common-prime(element of type Promotion, element of type xs:integer) = element of type Promotion
  common-prime(element of type Promotion, element of type Grade)      = element of type none
  common-prime(element student of type Person, element of type Student)       = element of type Student
  common-prime(element person, element student)                       = element student

3.7 Judgments for type promotion

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.

Notation

The judgment

Type1 can be promoted to Type2

holds if type Type1 can be promoted to type Type2.

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

A type can be promoted to itself


statEnv |- Type can be promoted to Type

type promotion is transitive

statEnv |- Type1 can be promoted to Type2      statEnv |- Type2 can be promoted to Type3

statEnv |- Type1 can be promoted to Type3

Notation

The judgment

Value1 against Type2 promotes to Value2

holds if value Value1 can be promoted to the value Value2 against the type Type2.

Example

For example, the following judgments hold

  1     of type xs:integer  against  xs:integer  is promoted to  1     of type xs:integer
  1     of type xs:integer  against  xs:decimal  is promoted to  1     of type xs:integer
  1     of type xs:integer  against  xs:float    is promoted to  1.0e0 of type xs:float
  1.0e0 of type xs:float    against  xs:double   is promoted to  1.0e0 of type xs:double

Note that type promotion changes the value, and only occurs if the input value does not matches 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

Value matches Type

Value against Type promotes to Value

If the value does not match the target type, but matches a type which can be promoted to the target type, then the value is cast to the target type.

statEnv |- Value1 matches Type1
statEnv |- Type1 can be promoted to Type2
statEnv |- Type1 != Type2
cast as Type2 (Value1) => Value2

statEnv |- Value1 against Type2 promotes to Value2

3.8 Judgments for the validate expression

XQuery supports XML Schema validation using the validate expression. This section describes the semantics of XML Schema validation, for the purpose of specifying its usage in XQuery.

Specifying XML Schema validation requires a fairly large number of auxiliary judgments. There are three main judgments used to describe the semantics of validation.

  • The "smatch" judgment stands for "structural" type matching. It takes as input a value and a type and either succeeds or fails. As opposed to type matching, structural type matching checks that the value given as input verifies both the name and structural constraints given by the type. This is natural since XML Schema must verify that both name and structural constraints are verified before accepting the document as valid or invalid. Once the document has been validated other XQuery operation only need to use type matching as described in [3.4.2 Matches].

  • 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 those three judgments, we first introduce auxiliary judgments used to describe specific parts of the XML Schema's semantics.

3.8.1 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:anyURIlist
  define type fs:anyURIlist { 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 ?

3.8.2 Extension

Notation

The judgment

statEnv |- Type1 extended by Type2 is Type

holds when the result of extending Type1 by Type2 is Type.

Semantics

This judgment is specified by the following rules.

statEnv |- Type1 = AttributeAll1 , ElementContent1      statEnv |- Type2 = AttributeAll2 , ElementContent2

statEnv |- Type1 extended by Type2 is (AttributeAll1 & AttributeAll2) , ElementContent1 , ElementContent2

3.8.3 Mixed content

Notation

The judgment

statEnv |- Type1 mixes to Type2

holds when the result of creating a mixed content from Type1 is Type2.

Semantics

This judgment is specified by the following rules.

statEnv |- Type = AttributeAll , ElementContent

statEnv |- Type mixes to AttributeAll , ( ElementContent & text* )

3.8.4 Adjusts

An element may optionally include the four built-in attributes xsi:type, xsi:nil, xsi:schemaLocation, or xsi:noNamespaceSchemaLocation.

Notation

The judgment

statEnv |- Mixed? Type1 adjusts to Type2

holds when the second type is the same as the first, with the four built-in attributes added, and with text nodes added if the type is mixed.

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 |- Type1 mixes to Type2
statEnv |- Type2 extended by BuiltInAttributes is Type3

statEnv |- mixed Type1 adjusts to Type3

Otherwise, just extend the type by the built-in attributes.

statEnv |- Type1 extended by BuiltInAttributes is Type2

statEnv |- Type1 adjusts to Type2

The definition of BuiltInAttributes appears in [3.2.4 Built-in type declarations].

3.8.5 Type resolution

Notation

The judgment

statEnv |- (TypeReference | TypeDerivation) resolves to TypeName { Type }

holds when a type reference or a type derivation resolves to the given type name and type content.

Semantics

This judgment is specified by the following rules.

If the type is omitted, it is resolved as the empty sequence type.

statEnv |- Derivation? Mixed? { () } resolves to TypeName { Type }

statEnv |- Derivation? Mixed? { } 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.typeDefn(TypeName) => 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 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 |- Mixed? Type adjusts to AdjustedType

statEnv |- restricts TypeName Mixed? { 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.typeDefn(TypeName) => define type TypeName Derivation? BaseMixed? { BaseType? }
statEnv |- BaseType? extended by Type is ExtendedType
statEnv |- Mixed? ExtendedType adjusts to AdjustedType

statEnv |- extends TypeName Mixed? { Type } resolves to TypeName { AdjustedType }

3.8.6 Element and attribute lookup

Element and attribute lookup used in validation is identical to the one used for type matching and is defined in [3.4.1 Element and attribute lookup].

3.8.7 Interleaving

Notation

The judgment

statEnv |- Value1 interleave Value2 yields Value3

holds if some interleaving of Value1 and Value2 yields Value3. 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 |- Value1 interleave Value2 yields Value3

statEnv |- Item,Value1 interleave Value2 yields Item,Value3

statEnv |- Value1 interleave Value2 yields Value3

statEnv |- Value1 interleave Item,Value2 yields Item,Value3

3.8.8 Filtering

Notation

The judgment

Value filter @QName => ()

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. The judgment

Value filter @QName => () or SimpleValue

holds if either of the previous two judgments hold.

Semantics

These judgments are defined using the auxiliary judgments

dynEnv |- Value1 on Axis => Value2

and

dynEnv |- Value1 on PrincipalNodeKind, NodeTest => Value2

which are defined in [5.2.1 Steps].

The filter judgments are defined as follows.

dynEnv |- Value1 on attribute:: => Value2
dynEnv |- Value2 on "attribute", QName => ()

Value1 filter @QName => ()

dynEnv |- Value1 on attribute:: => Value2
dynEnv |- Value2 on "attribute",QName => Value3
Value3 = attribute QName { SimpleValue }

Value1 filter @QName => SimpleValue

3.8.9 Structural matching

Introduction

We first extend the notion of type matching to handle both names and structures. The structural semantics of a type is given by the notion of structural matching.

A tree in the [XQuery 1.0 and XPath 2.0 Data Model] structurally matches a type in the [XPath/XQuery] type system, if and only if:

  • It verifies the structural constraints described by the type.

  • It verifies the name constraints described by the type.

Example

For example, the data model value

  element bib:pubdate of type [Anon3] { 1954, 1966, 1974, 1986 }

structurally matches the following type

  element of type [Anon3]
  define type [Anon3] { attribute country { xs:string }?, xs:integer* }

because the element name (bib:pubdate) matches the wildcard element in the type, the type annotation ([Anon3]) matches the type name, the attribute "country" is optional, and the content of that element is indeed a sequence of integers.

But the data model value

  element bib:pubdate of type [Anon3] { attribute pays { "France" }, 1954, 1966, 1974, 1986 }

does not structurally match the same type, since the element in the data model contains an attribute which is not described in the schema. This violates the structural requirement of the schema.

3.8.9.1 Structural nil matching

Notation

The judgment

statEnv |- Value nil-smatches Nillable? Type

holds when the given value structurally matches the given nillable type.

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 the value must structurally match the type.

Value filter @xsi:nil => ()
statEnv |- Value smatches Type

statEnv |- Value nil-smatches Type

If the type is nillable, and the xsi:nil attribute does not appear or is false, then the value must structurally match the type.

Value filter @xsi:nil => () or false
statEnv |- Value smatches Type

statEnv |- Value nil-smatches nillable Type

If the type is nillable, and the xsi:nil attribute is true, then the value must structurally match the attributes in the type only. The element content of the type is ignored.

Value filter @xsi:nil => true
statEnv |- Value smatches AttributeAll

statEnv |- Value nil-smatches nillable (AttributeAll, ElementContent)

3.8.9.2 Structural matching

Notation

The judgment

statEnv |- Value smatches Type

holds when the given value structurally matches the given type.

Semantics

This judgment is specified by the following rules.

The empty sequence structurally matches the empty sequence type.


statEnv |- () smatches ()

If two values structurally match two types, then their sequence structurally matches the corresponding sequence type.

statEnv |- Value1 smatches Type1
statEnv |- Value2 smatches Type2

statEnv |- Value1,Value2 smatches Type1,Type2

If a value structurally matches a type, then it also structurally matches a choice type where that type is one of the choices.

statEnv |- Value smatches Type1

statEnv |- Value smatches Type1|Type2

statEnv |- Value smatches Type2

statEnv |- Value smatches Type1|Type2

If two values structurally match two types, then their interleaving structurally matches the corresponding all group.

statEnv |- Value1 smatches Type1
statEnv |- Value2 smatches Type2
statEnv |- Value1 interleave Value2 yields Value

statEnv |- Value smatches Type1 & Type2

An optional type structurally matches a value of that type or the empty sequence.

statEnv |- Value smatches (Type | ())

statEnv |- Value smatches Type?

The following rules are used to structurally match a value against a sequence of zero (or one) or more types.


statEnv |- () smatches Type*

statEnv |- Value1 smatches Type      statEnv |- Value2 smatches Type*

statEnv |- Value1, Value2 smatches Type*

statEnv |- Value1 smatches Type      statEnv |- Value2 smatches Type*

statEnv |- Value1, Value2 smatches Type+

An element structurally matches an element type if the element type resolves to another element type, and the type annotation is derived from the type annotation of the resolved type, and the element value structurally matches the enclosed type of the resolved type.

Note that as opposed to the rule for type matching in [3.4.2 Matches], this rule also checks the content of the element.

statEnv |- ElementName lookup ElementType yields Nillable? TypeReference
statEnv |- TypeReference resolves to TypeName2 { Type }
statEnv |- TypeName1 derives from TypeName2
statEnv |- Value nil-smatches Nillable? Type

statEnv |- element ElementName of type TypeName1 { Value } smatches ElementType

The rule for attributes is similar.

statEnv |- AttributeName lookup AttributeType yields TypeReference
statEnv |- TypeReference resolves to TypeName2 { Type }
statEnv |- TypeName1 derives from TypeName2
statEnv |- Value nil-smatches Nillable? Type

statEnv |- attribute AttributeName of type TypeName1 { Value } smatches AttributeType

A document node structurally matches the corresponding document type.


statEnv |- document { Value } smatches document

A text node structurally matches the text node type.


statEnv |- text { String } smatches text

An atomic value structurally matches an atomic type if its type annotation derives from the atomic type.

statEnv |- AtomicTypeName1 derives from AtomicTypeName2

statEnv |- AtomicValue of type AtomicTypeName1 smatches AtomicTypeName2

An atomic value structurally matches "untyped" only if it is annotated with xs:anySimpleType.


statEnv |- AtomicValue of type xs:anySimpleType smatches untyped

Note

The above definition of structural matching, although complete and precise, does not give a simple means to compute structural 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 tree grammars. Computing structural matching can be done by computing if a given tree grammar recognizes the given data model value.

This document does not provide a complete algorithm to recognize a given tree by a tree grammar. The interested reader can consult the relevant literature, for instance [Languages], or [TATA].

3.8.10 Erasure

3.8.10.1 Simply erases

Notation

To define erasure, an auxiliary judgment is needed. The judgment

statEnv |- 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.

The concatenation of two non-empty sequences of values erases to the concatenation of their erasures with a separating space.

statEnv |- SimpleValue1 simply erases to String1 SimpleValue1 != ()
statEnv |- SimpleValue2 simply erases to String2 SimpleValue2 != ()

statEnv |- SimpleValue1,SimpleValue2 simply erases to fn:concat(String1," ",String2)

An atomic value erases to its string representation.


statEnv |- AtomicValue of type AtomicTypeName simply erases to dm:string-value(AtomicValue)

3.8.10.2 Erases

Notation

The judgment

statEnv |- Value1 erases to Value2

holds when the erasure of Value1 is Value2.

Semantics

This judgment is specified by the following rules.

The empty sequence erases to itself.


statEnv |- () 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.

statEnv |- Value1 erases to Value1'      statEnv |- Value1 not a simple value
statEnv |- Value2 erases to Value2'      statEnv |- Value2 not a simple value

statEnv |- Value1,Value2 erases to Value1',Value2'

The erasure of an element is an element that has the same name and the type xs:anyType and the erasure of the original content.

statEnv |- Value1 erases to Value2

statEnv |- element ElementName of type TypeName { Value1 } erases to element ElementName of type xs:anyType { Value2 }

The erasure of an attribute is an attribute that has the same name and the type xs:anySimpleType and the simple erasure of the original content labeled with xs:anySimpleType.

statEnv |- Value simply erases to String

statEnv |- attribute AttributeName of type TypeName { Value } erases to attribute AttributeName of type xs:anySimpleType { String of type xs:anySimpleType }

The erasure of a document is a document with the erasure of the original content.

statEnv |- Value1 erases to Value2

statEnv |- document { Value1 } erases to document { Value2 }

The erasure of a text node is itself.


statEnv |- text { String } erases to text { String }

The erasure of a simple value is the corresponding text node.

statEnv |- SimpleValue simply erases to String

statEnv |- SimpleValue erases to text { String }

3.8.11 Annotate

3.8.11.1 Simply annotate

Notation

The judgment

statEnv |- simply annotate as SimpleType1 ( SimpleValue ) => SimpleValue2

holds if the result of casting the SimpleValue1 to SimpleType is SimpleValue2.

Ed. Note: Issue: The simply annotate judgment is used to describe the behavior of validation of simple values. This operation is essentially similar to casting from string to an atomic value. It is not clear if this actually aligns to the behavior of casting as specified by the [XQuery 1.0 and XPath 2.0 Functions and Operators]. See [Issue-0156:  Casting and validation].

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 SimpleType1 (SimpleValue1) => SimpleValue2

statEnv |- simply annotate as SimpleType1|SimpleType2 (SimpleValue) => SimpleValue2

statEnv |- (simply annotate as SimpleType1 (SimpleValue1) => SimpleValue2) fails
statEnv |- simply annotate as SimpleType2 (SimpleValue1) => SimpleValue2

statEnv |- simply annotate as SimpleType1|SimpleType2 (SimpleValue) => SimpleValue2

The simple annotation rules for ?, +, * are similar.


statEnv |- simply annotate as SimpleType1? ( () ) => ()

statEnv |- simply annotate as SimpleType (SimpleValue1) => SimpleValue2

statEnv |- simply annotate as SimpleType? (SimpleValue1) => SimpleValue2


statEnv |- simply annotate as SimpleType* ( () ) => ()

statEnv |- simply annotate as SimpleType (SimpleValue1) => SimpleValue1'      statEnv |- simply annotate as SimpleType* (SimpleValue2) => SimpleValue2'

statEnv |- simply annotate as SimpleType* (SimpleValue1,SimpleValue2) => SimpleValue1',SimpleValue2'

statEnv |- simply annotate as SimpleType (SimpleValue1) => SimpleValue1'      statEnv |- simply annotate as SimpleType* (SimpleValue2) => SimpleValue2'

statEnv |- simply annotate as SimpleType+ (SimpleValue1,SimpleValue2) => SimpleValue1',SimpleValue2'

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.

Similar rules are assumed for the rest of the 19 XML Schema primitive types.

3.8.11.2 Nil-annotate

Notation

The judgment

statEnv |- nil-annotate as Nillable? Type ( Value1 ) => Value2

holds if it is possible to annotate value Value1 as if it had the nillable type Type and Value2 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.

Value1 filter @xsi:nil => ()
statEnv |- annotate as Type ( Value ) => Value2

statEnv |- nil-annotate as Type ( Value1 ) => Value2

If the type is nillable, and the xsi:nil attribute does not appear or is false, then it must be possible to annotate value Value1 as if it had the type Type.

Value1 filter @xsi:nil => () or false
statEnv |- annotate as Type ( Value1 ) => Value2

statEnv |- nil-annotate as nillable Type ( Value1 ) => Value2

If the type is nillable, and the xsi:nil attribute is true, then it must be possible to annotate value Value1 as if it had a type where the attributes in the type are kept and the element content of the type is ignored.

Value1 filter @xsi:nil => true
statEnv |- annotate as AttributeAll ( Value1 ) => Value2

statEnv |- nil-annotate as nillable (AttributeAll, ElementContent) ( Value1 ) => Value2

3.8.11.3 Annotate

Notation

The judgment

statEnv |- annotate as Type ( Value1 ) => Value2

holds if it is possible to annotate value Value1 as if it had type Type and Value2 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 Value1 and S corresponds to Type and X2 corresponds to Value2, the following should hold: annotate as Type ( Value1 ) => Value2.

Semantics

This judgment is specified by the following rules.

Annotating the empty sequence as the empty type yields the empty sequence.


statEnv |- annotate as () (()) => ()

Annotating a concatenation of values as a concatenation of types yields the concatenation of the annotated values.

statEnv |- annotate as Type1 (Value1) => Value1'
statEnv |- annotate as Type2 (Value2) => Value2'

statEnv |- annotate as Type1,Type2 (Value1,Value2) => Value1',Value2'

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 Type1 (Value1) => Value2

statEnv |- annotate as Type1|Type2 (Value1) => Value2

statEnv |- annotate as Type2 (Value1) => Value2

statEnv |- annotate as Type1|Type2 (Value1) => Value2

Annotating a value as an all group uses interleaving to decompose the original value and recompose the annotated value.

Ed. 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 Type1 ( Value1 ) => Value1'
statEnv |- annotate as Type2 ( Value2 ) => Value2'
statEnv |- Value1 interleave Value2 yields Value
statEnv |- Value1' interleave Value2' yields Value'

statEnv |- annotate as Type1 & Type2 ( Value ) => Value'

The annotation rules for ?, +, * are similar.

statEnv |- annotate as (Type | ())(Value1) => Value2

statEnv |- annotate as Type? (Value1) => Value2

statEnv |- annotate as Type (Value1) => Value1'      statEnv |- annotate as Type* (Value2) => Value2'

statEnv |- annotate as Type+ (Value1,Value2) => (Value1',Value2')


statEnv |- annotate as Type* ( () ) => ()

statEnv |- annotate as Type (Value1) => Value1'      statEnv |- annotate as Type* (Value2) => Value2'

statEnv |- annotate as Type* (Value1,Value2) => (Value1',Value2')

To annotate an element with no xsi:type attribute, first look up the 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 lookup ElementType yields Nillable? TypeReference
statEnv |- TypeReference resolves to TypeName { Type }
statEnv |- nil-annotate as Type Nillable? (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
statEnv |- XsiTypeReference = of type TypeName
statEnv |- ElementName lookup ElementType yields Nillable? of type BaseTypeName
statEnv |- TypeName derives from BaseTypeName
statEnv |- XsiTypeReference resolves to TypeName { Type }
statEnv |- nil-annotate as Type Nillable? (Value) => Value'

statEnv |- annotate as ElementType ( element ElementName of type xs:anyType { Value } ) => element ElementName of type TypeName { Value' }

Ed. Note: Issue: the treatment of xsi:type in the [XQuery 1.0: A Query Language for XML] document and in the formal semantics document still differ. See [Issue-0142:  Treatment of xsi:type in validation].

The rule for attributes is similar to the first rule for elements.

statEnv |- AttributeName lookup AttributeType yields TypeReference
statEnv |- TypeReference resolves to TypeName { Type }
statEnv |- nil-annotate as Type Nillable? (Value) => Value'

statEnv |- annotate as AttributeType ( attribute AttributeName of type xs:anySimpleType { Value } ) => attribute AttributeName of type TypeName { Value' }

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 as xs:anySimpleType ) => 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'

4 Basics

The organization of this section parallels the organization of Section 2 of the [XPath/XQuery] document.

4.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 evaluation context. This section specifies the environments that represent the context information used by [XPath/XQuery] expressions.

4.1.1 Static Context

The [XPath/XQuery] static inference rules use the environment group statEnv containing the environments built during static type checking and used during both static type checking and dynamic evaluation.

The following environments are maintained in the static environment group:

statEnv.xpath1.0_compatibility

The XPath 1.0 compatibility flag specifies whether the semantic rules for backward compatibility with XPath 1.0 are in effect.

The initial value of statEnv.xpath1.0_compatibility is false.

statEnv.namespace

The namespace environment maps namespace prefixes (NCNames) onto namespace URIs (URIs).

The namespace environment captures in-scope namespaces in the [XPath/XQuery] static context.

The initial namespace environment maps the following prefixes to the following URIS:

xmlhttp://www.w3.org/XML/1998/namespace
xshttp://www.w3.org/2001/XMLSchema
xsd http://www.w3.org/2001/XMLSchema-datatypes
xsi http://www.w3.org/2001/XMLSchema-instance
statEnv.default_namespace

The default namespace environment maps "element", and "function" to a namespace URI (a URI), as determined by the appropriate namespace declaration.

The default namespace environment captures the default namespace for element and type names and Default namespace for function names in the [XPath/XQuery] static context.

The initial default element namespace is the empty namespace. The initial default function namespace is:

http://www.w3.org/2002/11/xquery-functions

statEnv.typeDefn

The type definition environment maps type names (TypeNames) onto their global type definitions (Definitions).

The type definition environment captures in-scope schema definitions in the [XPath/XQuery] static context.

statEnv.elemDecl

The element declaration environment maps element names (ElementNames) onto their global element declarations (Definitions).

The element declaration environment does not have a counterpart in the [XPath/XQuery] static context. See [Issue-0159:  Element and attribute declarations in the static context].

statEnv.attrDecl

The attribute declaration environment maps attribute names (AttributeNames) onto their global attribute declarations (Definitions).

The attribute declaration environment does not have a counterpart in the [XPath/XQuery] static context. See [Issue-0159:  Element and attribute declarations in the static context].

statEnv.varType

The variable static type environment maps variable names (Variables) to their static types (Types).

The variable static type environment captures in-scope variables in the [XPath/XQuery] static context.

statEnv.funcType

The function declaration environment stores the static type signatures of functions. Because [XPath/XQuery] allows multiple built-in functions with the same name differing only in the number and signature of the arguments, this environment maps a QName to the set of all function declaration signatures of the form "define function QName (Type1, ..., Typen) return Type" each corresponding to a declaration of the function. (For user-defined functions the set will contain exactly one such declaration.)

The initial function declaration environment contains the signatures of the internal functions defined in [B Mapping of Overloaded Internal Functions].

statEnv.base_uri

The base uri environment contains a unique namespace URI (a URI).

The base uri environment captures the base URI in the [XPath/XQuery] static context.

Ed. Note: Issue: The static environment does not represent collations. See [Issue-0160:  Collations in the static environment]

Environments have an initial state when [expression/query] processing begins, containing, for example, the function signatures of all built-in functions.

A common use of the static environment is to expand QNames by looking up namespace prefixes in the statEnv.namespace environment.

The helper function expand is used to expand QNames by looking up the namespace prefix in statEnv.namespace. This function is defined as follows:

   statEnv |- expand(QName) = qname(URI, ncname)

or

   statEnv |- expand(QName) = qname(ncname)

the right hand side is a QName value (not a QName expression).

The helper expand function is defined as follows:

  • If QName matches NCName1:NCName2, and if statEnv.namespace(NCName1) = URI, then the expression yields qname(URI,NCName2). If the namespace prefix NCName1 is not found in statEnv.namespace, then the expression does not apply (that is, the inference rule will not match).

  • If QName matches NCName, NCName is an element or type name, and statEnv.default_namespace("element") = URI, then the expression yields qname(URI,NCName), where URI is the default namespace in effect.

  • If QName matches NCName, NCName is a function name, and statEnv.default_namespace("function") = URI, then the expression yields qname(URI,NCName), where URI is the default namespace in effect.

Ed. Note: The above rules could be given as proper inference rules defining the expand judgment.

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

statEnv [ namespace(NCName |-> URI) ] |- Expr*

statEnv |- namespace NCName = URI Expr*

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

This is the common idiom for passing new information in an environment using sub-expressions. In the case where the environment must be updated with a completely new component, the following notation is used:

statEnv [ namespace = (NewEnvironment) ]

4.1.2 Evaluation Context

dynEnv denotes the group of environments built and used only during dynamic evaluation.

The following environments are dynamic:

dynEnv.funcDefn

The dynamic function environment maps a function declaration name and parameter signature of the form "QName (Type1, ..., Typen)" to the remainder of the corresponding function definition, which is either the special constant #BUILT-IN, or the function's body, and the list of variables, which are the function's formal parameters, on the form "(Expr, Variable1, ,..., Variablen)".

The initial function environment maps the signatures of the internal functions defined in [B Mapping of Overloaded Internal Functions] and the signatures of the functions defined in [XQuery 1.0 and XPath 2.0 Functions and Operators] to #BUILT-IN.

dynEnv.varValue

The dynamic value environment maps a variable name (QName) onto the variable's current value (Value).

Ed. Note: Somewhere an exact definition of what is in the initial environments is needed. Notice that for XPath this is partially defined by the containing language. See [Issue-0115:  What is in the default context?].

The following Formal Semantics built-in variables represent the context item, context position , and context size properties of the evaluation context:

Built-in Variable  Represents:
$fs:dotcontext item
$fs:positioncontext position
$fs:lastcontext size
$fs:implicitTimezoneimplicit timezone

Variables with the "fs" namespace prefix are reserved for use in the definition of the Formal Semantics. It is a static error to define a variable in the "fs" namespace.

Values of $fs:dot, $fs:position and $fs:last can be obtained by invoking the fn:context-item(), fn:position() and fn:last() functions, respectively. The context document, can be obtained by application of the fn:root() function.

The variable $fs:implicitTimezone is used to represent the implicit timezone, and is used by the timezone related functions in [XQuery 1.0 and XPath 2.0 Functions and Operators].

Ed. Note: The Formal Semantics does not yet model the semantics of timezone related functions.

Ed. Note: The following dynamic contexts have no formal representation yet: current-date, current-time and current-dateTime. See [Issue-0114:  Dynamic context for current date and time]

4.2 Input Functions

[XPath/XQuery] has three functions that provide access to input data: input, collection, and document. The dynamic semantics of these three input functions are described in more detail in [XQuery 1.0 and XPath 2.0 Functions and Operators]. The static typing for these function is still an open issue (See [Issue-0137:  Typing of input functions]).

4.3 Expression Processing

This section gives background material about the [XPath/XQuery] data model. More information on the [XPath/XQuery] data model can be found in [2.3 Data Model].

4.4 Types

4.4.1 Type Checking

This section gives background material about [XPath/XQuery] type checking. More information on the [XPath/XQuery] type system can be found in [2.4 Schemas and types] and [3 The XQuery type system].

4.4.2 SequenceType

Introduction

SequenceTypes can be used in [XPath/XQuery] to refer to a type imported from a schema (see [6 The Query Prolog]). SequenceTypes are used to declare the types of function parameters and in several kinds of [XPath/XQuery] expressions.

The syntax of SequenceTypes is described by the following grammar productions.

[88 (XQuery)]   SequenceType   ::=   (ItemType OccurrenceIndicator) |  "empty"
[89 (XQuery)]   ItemType   ::=   (("element" |  "attribute") ElemOrAttrType?)
|  "node"
|  "processing-instruction"
|  "comment"
|  "text"
|  "document"
|  "item"
|  AtomicType
|  "untyped"
|  <"atomic" "value">
[90 (XQuery)]   ElemOrAttrType   ::=   (QName (SchemaType |  SchemaContext?)) |  SchemaType
[91 (XQuery)]   SchemaType   ::=   <"of" "type"> QName
[83 (XQuery)]   SchemaContext   ::=   "context" SchemaGlobalContext ("/" SchemaContextStep)*
[84 (XQuery)]   SchemaGlobalContext   ::=   QName |  <"type" QName>
[85 (XQuery)]   SchemaContextStep   ::=   QName
[92 (XQuery)]   AtomicType   ::=   QName
[93 (XQuery)]   OccurrenceIndicator   ::=   ( |  "*" |  "+" |  "?")?

The semantics of SequenceTypes is defined by means of normalization rules from SequenceTypes to the [XPath/XQuery] type system (see [3 The XQuery type system]).

Core Grammar

The core grammar productions for sequence types are:

[64 (Core)]   SequenceType   ::=   (ItemType OccurrenceIndicator) |  "empty"
[65 (Core)]   ItemType   ::=   (("element" |  "attribute") ElemOrAttrType?)
|  "node"
|  "processing-instruction"
|  "comment"
|  "text"
|  "document"
|  "item"
|  AtomicType
|  "untyped"
|  <"atomic" "value">
[66 (Core)]   ElemOrAttrType   ::=   (QName (SchemaType |  SchemaContext?)) |  SchemaType
[67 (Core)]   SchemaType   ::=   <"of" "type"> QName
[59 (Core)]   SchemaContext   ::=   "context" SchemaGlobalContext ("/" SchemaContextStep)*
[60 (Core)]   SchemaGlobalContext   ::=   QName |  <"type" QName>
[61 (Core)]   SchemaContextStep   ::=   QName
[68 (Core)]   AtomicType   ::=   QName
[69 (Core)]   OccurrenceIndicator   ::=   ( |  "*" |  "+" |  "?")?

Ed. Note: Note that normalization on SequenceTypes does not occur during the normalization phase but whenever a dynamic or static rule requires it. The reason for this deviation from the processing model is that the result of SequenceType normalization is not part of the [XPath/XQuery] syntax (See issue [Issue-0089:  Syntax for types in XQuery]). SequenceType normalization is the only occurrence of such a deviation in the formal semantics.

4.4.2.1 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 [3.4 Judgments for type matching].

Sequence type matching is defined between a value and a type, rules to normalize a sequence type to the type system are necessary.

Notation

To define normalization of SequenceTypes to the type system, the following auxiliary mapping rule is used.

 
[SequenceType]sequencetype
==
Type

specifies that SequenceType is mapped to Type, in the 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 type is mapped to the empty sequence type in the [XPath/XQuery] type system.

 
[empty]sequencetype
==
[()]sequencetype

The SequenceType component with type SchemaType is mapped directly into the [XPath/XQuery] type system.

 
[element SchemaType]sequencetype
==
element SchemaType
 
[attribute SchemaType]sequencetype
==
attribute SchemaType

The mapping still does not handle SequenceTypes using SchemaContext (See [Issue-0138:  Semantics of Schema Context]). The two following rules map references to a global element or attribute, without taking the schema context into account.

 
[element QName]sequencetype
==
element QName
 
[attribute QName]sequencetype
==
attribute QName

Document nodes, text nodes, untyped and atomic types are left unchanged.

 
[text]sequencetype
==
text
 
[document]sequencetype
==
document
 
[untyped]sequencetype
==
untyped
 
[AtomicType]sequencetype
==
AtomicType

Processing instruction and comment types are ignored. See [Issue-0105:  Types for nodes in the data model.].

 
[comment]sequencetype
==
 
[processing-instruction]sequencetype
==

The SequenceType components "node", "item", and "atomic value" correspond to wildcard types. node indicates that any node is allowed, "atomic value" indicates that any atomic (not list) value is allowed, and item indicates that any node or atomic value is allowed. The following mapping rules make use of the corresponding wildcard types.

 
[node]sequencetype
==
(element | attribute | text | document)
 
[item]sequencetype
==
(element | attribute | text | document | xs:string | xs:decimal | ... )
 
[atomic value]sequencetype
==
(xs:string | xs:decimal | ... )

Ed. Note: Jerome: The Formal Semantics makes use of fs:numeric which is not in XML Schema. This is necessary for the specification of some of XPath type conversion rules. See [Issue-0127:  SequenceType limitations].

4.4.3 Type Conversions

Introduction

Some expressions do not require their operands to exactly match the expected type. For example, function parameters and returns expect a value of a particular type, but automatically perform certain type conversions, such as extraction of atomic values from nodes, promotion of numeric values, and implicit casting of untyped values. The conversion rules for function parameters and returns are discussed in [5.1.4 Function Calls]. Other operators that provide special conversion rules include arithmetic operators, which are discussed in [5.4 Arithmetic Expressions], and value comparisons, which are discussed in [5.5.1 Value Comparisons].

Some special conversion rules: atomization, effective boolean value, and fallback conversions, are used in several places in the language.

4.4.3.1 Atomization

Notation

Atomization, denoted []Atomize, converts an item sequence into a sequence of atomic values.

Normalization

The rule below examines each item in the item sequence. If it is an atomic value, it is simply returned. If it is a node value, its typed content is returned.

 
[Expr]Atomize
==
for $item in (Expr) return
   typeswitch ($item)
    case $value as atomic value return $value
    default $node return fn:data($node)
4.4.3.2 Effective Boolean Value

Notation

The function []Effective_Boolean_Value takes an arbitrary value and converts it into a boolean value by applying the function fn:boolean().

Normalization

The effective boolean value is obtained through the following normalization rule.

 
[Expr]Effective_Boolean_Value
==
fn:boolean(Expr)

4.5 Variable Bindings

The semantics of variable bindings is handled by means of changing the static and dynamic environments. This is specified in the sections where variables are bound ([5.8 [For/FLWOR] Expressions], [5.11 Quantified Expressions], [5.12.2 Typeswitch], and [6.5 Function Definitions]) and where variables are used ([5.1.2 Variables]).

4.6 Errors and Conformance

This section describes error handling and conformance levels.

Ed. Note: Issue: Error handling is not formally specified. See [Issue-0094:  Static type errors and warnings]

Ed. Note: Issue: Conformance levels are not formally specified. See [Issue-0169:  Conformance Levels]

5 Expressions

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

[25 (XQuery)]   Expr   ::=   OrExpr
[13 (XPath)]   XPath   ::=   ExprSequence?

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 [XPath/XQuery] 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 production for expressions is:

[22 (Core)]   Expr   ::=   ForExpr
|  ForExpr

5.1 Primary Expressions

Primary expressions are the basic primitives of the language.They include literals, variables, function calls, and the use of parentheses to control precedence of operators.

[62 (XQuery)]   PrimaryExpr   ::=   Literal |  FunctionCall |  ("$" VarName) |  ParenthesizedExpr
[13 (XQuery)]   VarName   ::=   QName

Core Grammar

The core grammar productions for primary expressions are:

[41 (Core)]   PrimaryExpr   ::=   Literal |  FunctionCall |  ("$" VarName) |  ParenthesizedExpr
[12 (Core)]   VarName   ::=   QName

5.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.

[79 (XQuery)]   Literal   ::=   NumericLiteral |  StringLiteral
[78 (XQuery)]   NumericLiteral   ::=   IntegerLiteral |  DecimalLiteral |  DoubleLiteral
[1 (XQuery)]   IntegerLiteral   ::=   Digits
[2 (XQuery)]   DecimalLiteral   ::=   ("." Digits) |  (Digits "." [0-9]*)
[3 (XQuery)]   DoubleLiteral   ::=   (("." Digits) |  (Digits ("." [0-9]*)?)) ([e] | [E]) ([+] | [-])? Digits
[4 (XQuery)]   StringLiteral   ::=   (["] ((" ") |  [^"])* ["]) |  (['] ((' ') |  [^'])* ['])
[5 (XQuery)]   URLLiteral   ::=   (["] ((" ") |  [^"])* ["]) |  (['] ((' ') |  [^'])* ['])

Normalization

All literals are core expressions, therefore no normalization rules are required for literals.

Core Grammar

The core grammar productions for literals are:

[55 (Core)]   Literal   ::=   NumericLiteral |  StringLiteral
[54 (Core)]   NumericLiteral   ::=   IntegerLiteral |  DecimalLiteral |  DoubleLiteral
[1 (Core)]   IntegerLiteral   ::=   Digits
[2 (Core)]   DecimalLiteral   ::=   ("." Digits) |  (Digits "." [0-9]*)
[3 (Core)]   DoubleLiteral   ::=   (("." Digits) |  (Digits ("." [0-9]*)?)) ([e] | [E]) ([+] | [-])? Digits
[4 (Core)]   StringLiteral   ::=   (["] ((" ") |  [^"])* ["]) |  (['] ((' ') |  [^'])* ['])
[5 (Core)]   URLLiteral   ::=   (["] ((" ") |  [^"])* ["]) |  (['] ((' ') |  [^'])* ['])

Static Type Analysis

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


statEnv |- IntegerLiteral : xs:integer

Dynamic Evaluation

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


dynEnv |- IntegerLiteral => dm:atomic-value(IntegerLiteral, xs:integer)

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

Static Type Analysis


statEnv |- DecimalLiteral : xs:decimal

Dynamic Evaluation


dynEnv |- DecimalLiteral => dm:atomic-value(DecimalLiteral, xs:decimal)

Static Type Analysis


statEnv |- DoubleLiteral : xs:double

Dynamic Evaluation


dynEnv |- DoubleLiteral => dm:atomic-value(DoubleLiteral, xs:double)

Static Type Analysis


statEnv |- StringLiteral : xs:string

Dynamic Evaluation


dynEnv |- StringLiteral => dm:atomic-value(StringLiteral, xs:string)

Ed. Note: MFF: Phil has noted that the data model should support primitive literals in their lexical form, in which case no explicit dynamic semantic rule would be necessary. See [Issue-0118:  Data model syntax and literal values].

5.1.2 Variables

Introduction

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

Normalization

A variable is a core expression, therefore no normalization rule is required for a variable.

Static Type Analysis

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

statEnv.varType(Variable) = Type

statEnv |- Variable : Type

If the variable is not bound in the environment, the system raises an error.

Dynamic Evaluation

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

dynEnv.varValue(Variable) = Value

dynEnv |- Variable => Value

If the variable is not bound in the environment, the system raises an error.

5.1.3 Parenthesized Expressions

[80 (XQuery)]   ParenthesizedExpr   ::=   "(" ExprSequence? ")"

The formal definition of parenthesized expressions is in [5.3 Sequence Expressions].

Core Grammar

The core grammar production for parenthesized expressions is:

[56 (Core)]   ParenthesizedExpr   ::=   "(" ExprSequence? ")"

5.1.4 Function Calls

Introduction

A function call consists of a QName followed by a parenthesized list of zero or more expressions.

[81 (XQuery)]   FunctionCall   ::=   <QName "("> (Expr ("," Expr)*)? ")"

Because [XPath/XQuery] performs implicit operations when doing function calls, a normalization step is required.

Notation

Normalization of function calls uses an auxiliary mapping rule, []FormalArgument, used to map the formal arguments of a function call.

There are two variants of this mapping rule. If the required type of the formal argument is a sequence of an atomic type, the following rule is applied:

 
[Expr]FormalArgument
==
[[Expr]Expr]Atomize

If the required type of the formal argument is not an optional atomic type or a sequence of atomic types, the expression is simply mapped to its corresponding core expression:

 
[Expr]FormalArgument
==
[Expr]Expr

Ed. Note: The above two rules should explicitly look up whether the signatures of the argument in question has atomic type or not.

Normalization

First, each argument in a function call is normalized to its corresponding core expression by applying []FormalArgument.

 
[ QName (Expr1, ..., Exprn) ]Expr
==
QName ( [Expr1]FormalArgument, ..., [Exprn]FormalArgument )

Note that this normalization rule depends on the static environment containing function signatures and is the only place where we exploit the implicit presence of statEnv.

Ed. Note: Moved the outermost normalization to the (dynamic!) evaluation rule as we have no idea at this point what type the context expects...and it does not seem to be necessary.

Core Grammar

The core grammar production for function calls is:

[57 (Core)]   FunctionCall   ::=   <QName "("> (Expr ("," Expr)*)? ")"

Static Type Analysis

Based on the function's name, the possible function signatures are retrieved from the static environment. If the function is not present in the environment with an appropriate signature, an error is raised. The type of each actual argument to the function must be a subtype of a type that is promotable to the corresponding formal argument type of the function.

statEnv |- QName => qname
statEnv.funcType(qname) = { FuncDecl1, ..., FuncDeclm }
FuncDecli = define function qname(Type1, ..., Typen) as Type
statEnv |- Expr1 : Type1'     Type1' <: Type1''     Type1'' can be promoted to Type1
...
statEnv |- Exprn : Typen'     Typen' <: Typen''     Typen'' can be promoted to Typen

statEnv |- QName (Expr1, ..., Exprn) : Type

Notice that the function body is not typed for each invocation: static typing of the declaration itself guarantees that the function will, indeed, always return a value of the declared return Type.

Dynamic Evaluation

Based on the function's name and argument types, the function body is retrieved from the dynamic environment. If the function is not present in the environment, an error is raised. The rule first evaluates each actual function argument expression. Next a match is searched for among the function's possible declaration signatures, retrieved from the statEnv.funcType static environment component. If the function is not present in the environment, or there is no matching declaration signature, a type error is raised. Otherwise, the function body and formal variables are obtained from dynEnv.funcDefn for the matching declaration signature. The rule then extends by binding each formal variable to its corresponding value converted as required for the expected type and backwards compatibility flag, and evaluates the body of the function in the new environment. The resulting value is the value of the function call.

Ed. Note: XPath 1.0 compatibility: Rules for converting function arguments not implemented yet. See [Issue-0178:  Semantics of XPath 1.0 compatibility].

statEnv |- QName => qname
statEnv.funcType(qname) = { FuncDecl1, ..., FuncDeclm }
FuncDecli = define function qname(Type1, ..., Typen) as Type
dynEnv |- Expr1 => Value1 ... dynEnv |- Exprn => Valuen
statEnv |- Value1 against Type1 promotes to Value1'
...
statEnv |- Valuen against Typen promotes to Valuen'
dynEnv.funcDefn(qname(Type1, ..., Typen)) = (Expr, Variable1, ... , Variablen)
dynEnv [ varValue = ( Variable1 |-> Value1'; ...; Variablen |-> Valuen') ] |- Expr => Value
statEnv |- Value against Type promotes to Value'

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

Note that the function body is evaluated in the default (top-level) environment extended with just the parameter bindings. Note also that input values and output values are matched against the types declared for the function. If static analysis was performed, all these checks are guaranteed to be true and may be omitted.

Built-in functions are invoked similarly except they are applied directly.

statEnv |- QName => qname
statEnv.funcType(qname) = { FuncDecl1, ..., FuncDeclm }
FuncDecli = define function qname(Type1, ..., Typen) as Type
dynEnv |- Expr1 => Value1 ... dynEnv |- Exprn => Valuen
statEnv |- Value1 against Type1 promotes to Value1'
...
statEnv |- Valuen against Typen promotes to Valuen'
dynEnv.funcDefn(qname(Type1, ..., Typen)) = #BUILT-IN
qname(Value1', ..., Valuen') => Value
statEnv |- Value against Type promotes to Value'

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

Primitive Function Application use the following additional auxiliary judgment to evaluate the primitive function application:

"The primitive function F (from data model, type constructor, or functions and operators) applied to the given parameter values yields the specified result value"

F(Value1, ..., Valuen) => Value

Ed. Note: Issue: Primitive function applications must be defined more precisely. See [Issue-0179:  Primitive function applications]

5.1.5 Comments

[6 (XQuery)]   ExprComment   ::=   "{--" [^}]* "--}"

Comments are lexical constructs only, and have no meaning within the query and therefore have no Formal Semantics.

5.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.

[42 (XQuery)]   PathExpr   ::=   ("/" RelativePathExpr?) |  ("//" RelativePathExpr) |  RelativePathExpr
[43 (XQuery)]   RelativePathExpr   ::=   StepExpr (("/" |  "//") StepExpr)*

Core Grammar

PathExpr and RelativePathExpr are fully normalized. There for, there is no corresponding production in the core. The grammar of path expressions in the core starts with the StepExpr production.

Normalization

Absolute path expressions are path expressions starting with the / symbol, indicating that the expression must be applied on the root node in the current context. Remember that the root node in the current context is the topmost ancestor of the context node. The following two rules are used to normalize absolute path expressions to relative ones, and rely on the use of the fn:root() function, which computes the document node from the context node.

 
["/"]Expr
==
fn:root( $fs:dot )
 
["/" RelativePathExpr]Expr
==
[fn:root( $fs:dot ) "/" RelativePathExpr]Expr

Ed. Note: Some of the semantics of the root expression '/' are still undefined. For instance, what should the semantics of '/' be in case of a document fragment (e.g., created using XQuery element constructor). See [Issue-0123:  Semantics of /].

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 encapsulating call of the fs:distinct-doc-order function then ensures that the result is in document order without duplicates. The evaluation context is carefully set up (using notably the at $fs:position position binding in the for expression to bind the position.

Note that applying sorting by document order is enforces the restriction that input and output sequences contains only nodes.

 
[StepExpr1 "/" StepExpr2]Expr
==
fs:distinct-doc-order (
  let $fs:sequence := fs:distinct-doc-order( [StepExpr1]Expr ) return
  let $fs:last := fn:count($fs:sequence) return
  for $fs:dot at $fs:position in $fs:sequence return
    [StepExpr2]Expr
)

5.2.1 Steps

Introduction

[44 (XQuery)]   StepExpr   ::=   (ForwardStep |  ReverseStep |  PrimaryExpr) Predicates
[73 (XQuery)]   ForwardStep   ::=   (ForwardAxis NodeTest) |  AbbreviatedForwardStep
[74 (XQuery)]   ReverseStep   ::=   (ReverseAxis NodeTest) |  AbbreviatedReverseStep

Core Grammar

The core grammars productions for XPath steps are:

[29 (Core)]   StepExpr   ::=   ForwardStep |  ReverseStep |  PrimaryExpr
[52 (Core)]   ForwardStep   ::=   ForwardAxis NodeTest
[53 (Core)]   ReverseStep   ::=   ReverseAxis NodeTest

Notation

Step expressions can be followed by predicates. Normalization of predicates uses the following auxiliary mapping rule: []Predicates.

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.

In the case predicates are applied on a forward step, the input sequence is first sorted in document order and duplicates are removed. The context is changed to bind the appropriate variable in document order.

Note that applying sorting by document order is enforces the restriction that input and output sequences contains only nodes.

 
[ForwardStep Predicates "[" Expr "]"]Expr
==
let $fs:sequence := fs:distinct-doc-order( [ForwardStep Predicates]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 ()

In the case predicates are applied on a reverse step, the input sequence is first sorted in document order and duplicates are removed. The context is changed such that the position variable is bound in reverse document order.

Note that applying sorting by document order is enforces the restriction that input and output sequences contains only nodes.

 
[ReverseStep Predicates "[" Expr "]"]Expr
==
let $fs:sequence := fs:distinct-doc-order( [ReverseStep Predicates]Expr ) return
let $fs:last := fn:count($fs:sequence) return
for $fs:dot at $fs:new in $fs:sequence return
let $fs:position := $fs:last - $fs:new + 1 return
  if [Expr]Predicates then $fs:dot else ()

In the case predicates are applied on a primary expression, the input sequence is processed in sequence order and the context is bound as in the case of forward axis. In that case, the sequence can contain both nodes and atomic values.

 
[PrimaryExpr Predicates "[" Expr "]"]Expr
==
let $fs:sequence := [PrimaryExpr Predicates]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 ()

The []Predicates function is specified in [5.2.2 Predicates].

5.2.1.1 Axes

Introduction

[63 (XQuery)]   ForwardAxis   ::=   <"child" "::">
|  <"descendant" "::">
|  <"attribute" "::">
|  <"self" "::">
|  <"descendant-or-self" "::">
[64 (XQuery)]   ReverseAxis   ::=   <"parent" "::">
[50 (XPath)]   ForwardAxis   ::=   <"child" "::">
|  <"descendant" "::">
|  <"attribute" "::">
|  <"self" "::">
|  <"descendant-or-self" "::">
|  <"following-sibling" "::">
|  <"following" "::">
|  <"namespace" "::">
[51 (XPath)]   ReverseAxis   ::=   <"parent" "::">
|  <"ancestor" "::">
|  <"preceding-sibling" "::">
|  <"preceding" "::">
|  <"ancestor-or-self" "::">

Core Grammar

The core grammars productions for XPath axis are:

[42 (Core)]   ForwardAxis   ::=   <"child" "::">
|  <"descendant" "::">
|  <"attribute" "::">
|  <"self" "::">
|  <"descendant-or-self" "::">
|  <"following-sibling" "::">
|  <"following" "::">
|  <"namespace" "::">
[43 (Core)]   ReverseAxis   ::=   <"parent" "::">
|  <"ancestor" "::">
|  <"preceding-sibling" "::">
|  <"preceding" "::">
|  <"ancestor-or-self" "::">

Notation

Some auxiliary grammar productions and judgments are introduced to structure the semantic rules for axes and node tests. The first is used to capture the principal node kind associated with each axis:

[61 (Formal)]   PrincipalNodeKind   ::=   "element" |  "attribute" |  "namespace"
[59 (Formal)]   Axis   ::=   ForwardAxis |  ReverseAxis

Notation

The principal node kind for each axis is specified using the following judgment.

Axis principal PrincipalNodeKind

Notation

The following auxiliary grammar production defines Filters, which denote either an axis, or a node test in the context of a principal node kind. An Axis merely combines the forward and reverse axes to allow judgments that range over both.

[59 (Formal)]   Axis   ::=   ForwardAxis |  ReverseAxis
[60 (Formal)]   Filter   ::=   Axis |  (PrincipalNodeKind NodeTest)

Notation

The semantics of filters is defined with three auxiliary judgments. The first judgment defines the effect of a filter on a value, and is used in the dynamic semantics. This judgment should be read as follows: in the current context (i.e., with respect to the dynamic environment dynEnv.varValue), applying the Filter on Value1 yields Value2:

dynEnv |- Filter on Value1 => Value2

The second judgment is defining the effect of a filter (either an axis or a nodetest) on a type and is used in the static semantics. This judgment should be read as follows: in the current context, (i.e., with respect to the the static environment statEnv.varType), applying the filter Filter on type Type1 yields the type Type2

statEnv |- Filter on Type1 : Type2

The last judgment allows an additional type environment, localTypeEnv. This "local" type environment maps variables to types (in the same way as statEnv.varType), and is used when computing the static type of the descendant axis.

statEnv ; localTypeEnv |- Filter on Type1 : Type2

These judgments will be defined separately for axes and node tests below.

Ed. Note: Explain the judgments in detail, maybe similarly to in section 3.2.

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:dot) = Type1
statEnv |- Axis on Type1 : Type2
Axis principal PrincipalNodeKind
statEnv |- PrincipalNodeKind, NodeTest on Type2 : Type3

statEnv |- Axis NodeTest : Type3

Here are the common set of inference rules defining the static semantics of filters. Essentially, these rules are used to process complex types through a filter, breaking the types down to the type of a node or of a value. The semantics of a filter applied to a node or value type is then specific to each Axis and NodeTest.


statEnv |- Filter on () : ()


statEnv |- Filter on none : none

statEnv |- Filter on Type1 : Type3
statEnv |- Filter on Type2 : Type4

statEnv |- Filter on Type1,Type2 : Type3,Type4

statEnv |- Filter on Type1 : Type3
statEnv |- Filter on Type2 : Type4

statEnv |- Filter on Type1|Type2 : Type3|Type4

statEnv |- Filter on Type1 : Type3
statEnv |- Filter on Type2 : Type4

statEnv |- Filter on Type1&Type2 : Type3&Type4

The cases for specific axis and node test filters are given in the axis and node test sections below.

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 the filter judgment as follows.

dynEnv.varValue($fs:dot) = Value1
dynEnv |- Axis on Value1 => Value2
Axis principal PrincipalNodeKind
dynEnv |- PrincipalNodeKind, NodeTest on Value2 => Value3

dynEnv |- Axis NodeTest => Value3

Here are the common set of inference rules defining the dynamic semantics of filters. These rules apply filters to a sequence, by breaking the sequence down to a node or value.


dynEnv |- Filter on () => ()

dynEnv |- Filter on Value1 => Value3
dynEnv |- Filter on Value2 => Value4

dynEnv |- Filter on Value1,Value2 => Value3,Value4

Ed. Note: Jerome: These rules fetaure a notational abuse! Value1,Value2 indicates the concatenation of Value1 and Value2, and is used for both constructing a new sequence and deconstructing it. When doing the construction, it is equivalent to applying the op:concatenate operator. The Formal Semantics specification should use more consistent notation for data model constructions and deconstruction. See also [Issue-0118:  Data model syntax and literal values].

The semantics of a filter applied to a specific axis or nodetest is given in the appropriate section below.

Normalization

The semantics of the following(-sibling) and preceding(-sibling) axes are expressed by mapping them to core expressions, all other axes are part of core [XPath/XQuery] and therefore are left unchanged through normalization.

 
[following-sibling:: NodeTest]Expr
==
typeswitch ($fs:dot)
  case $v as attribute return ()
  default $v return
    (for $fs:new in (for $fs:dot in (for $fs:dot in $fs:dot return parent::node() ) return child::NodeTest) return
      if dm:node-before($fs:dot,$fs:new) then $fs:new else ())

Ed. Note: Should all mappings be unfolded all the way to the core language like the above one?

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

Otherwise, the forward axis is part of the core [XPath/XQuery] and handled by the Axis/NodeTest semantics below:

 
[child:: NodeTest]Expr
==
child:: NodeTest
 
[attribute:: NodeTest]Expr
==
attribute:: NodeTest
 
[self:: NodeTest]Expr
==
self:: NodeTest
 
[descendant:: NodeTest]Expr
==
descendant:: NodeTest
 
[descendant-or-self:: NodeTest]Expr
==
descendant-or-self:: NodeTest
 
[namespace:: NodeTest]Expr
==
namespace:: NodeTest

Reverse axes:

 
[preceding-sibling:: NodeTest]Expr
==
for $fs:new in (for $fs:dot in (for $fs:dot in $fs:dot return parent::node()) return child::NodeTest) return
  if dm:node-before($fs:new,$fs:dot) then $fs:new else ()
 
[preceding:: NodeTest]Expr
==
[ancestor-or-self::node()/preceding-sibling::node()/descendant-or-self::NodeTest]Expr

Otherwise, the reverse axis is part of the core [XPath/XQuery] and is handled by the Axis/NodeTest semantics below.

 
[parent:: NodeTest]Expr
==
parent:: NodeTest
 
[ancestor:: NodeTest]Expr
==
ancestor:: NodeTest
 
[ancestor-or-self:: NodeTest]Expr
==
ancestor-or-self:: NodeTest

Finally, the principal node kind of each axis is enumerated by the following rules (given here because they are used both by the static and dynamic semantic rules).


attribute:: principal attribute


namespace:: principal namespace

Axis != attribute::     Axis != namespace::

Axis principal element

Static Type Analysis

The following rules define the static semantics of the filter judgment when applied to an Axis.

The type for the self axis is the same type as the type of the context node.


statEnv |- self:: on NodeType : NodeType

In case of elements, the type of the child axis is obtained by extracting the children types out of the content model describing the type of the context node.


statEnv |- child:: on element qname { AttrType, ChildType } : ChildType

Ed. Note: [Kristoffer/XSL] Need to add filters for all cases.

The type of the attribute axis is obtained by extracting the attribute types out of the content model describing the type of the context node.


statEnv |- attribute:: on element qname { AttrType, ChildType } : AttrType

Ed. Note: [Kristoffer/XSL] Need to add filters for all cases.

The type for the parent axis is either an element, a document (for document elements), or empty.


statEnv |- parent:: on element : (element|document)?

Ed. Note: Better typing for the parent axis is still an open issue. See [Issue-0080:  Typing of parent].

The type for the namespace axis is always empty.


statEnv |- namespace:: on NodeType : ()

Ed. Note: Jerome: The type of namespace nodes is still an open issue. See [Issue-0105:  Types for nodes in the data model.].

The types for the descendant, and descendant-or-self, ancestor, and ancestor-or-self axis are implemented through recursive application of the children and parent filters. The corresponding inference rules use the auxiliary filter judgment with a local type environment. This local type environment is used to keep track of the visited elements in order to deal with recursive types.

statEnv ; { } |- descendant:: on Type : Type'

statEnv |- descendant:: on Type : Type'

The following two rules are used to deal with global elements. Global elements need careful treatment here in order to deal with possible recursion. Notably, if the global element has been seen before, then the rule terminates and returns the union of all types already visited in the local environment.

localTypeEnv(qname) = Type
localTypeEnv = { Type1, Type2, ... }

statEnv |- descendant:: on element qname : (Type1|Type2|...)*

localTypeEnv(qname) is an error
statEnv.elemDecl(qname) = define element qname TypeReference
TypeReference resolves to TypeName { Type }
statEnv ; localTypeEnv[qname : Type] |- descendant:: on Type : Type'

statEnv localTypeEnv |- descendant:: on element qname Type'

Ed. Note: Peter: I need yet to figure out, whether this works, there still appear a few glitches. See [Issue-0132:  Typing for descendant].

In all other cases, the following rule applies

statEnv |- child:: on NodeType : Type1
statEnv |- descendant:: on Type1 : Type2

statEnv |- descendant:: on NodeType : Type1,Type2

statEnv |- self:: on NodeType : Type1
statEnv |- descendant:: on Type1 : Type2

statEnv |- descendant-or-self:: on NodeType : Type1,Type2

The type for the ancestor axis is the element*,document? type indicating that it includes elements and possibly a document element.


statEnv |- ancestor:: on NodeType : element*

statEnv |- self:: on NodeType : Type1
statEnv |- ancestor:: on Type1 : Type2

statEnv |- ancestor-or-self:: on NodeType : Type1, Type2

In all the other cases, the filter application results in an empty type.

statEnv |- AxisName:: on NodeType : () otherwise.

Ed. Note: KHR: "otherwise" rules should be avoided and specify the cases exhaustively.

Dynamic Evaluation

The inference rules below indicate for each axis whether a particular node should be considered further or whether the node should be left out. Therefore, each rule either returns the input node, or returns the empty sequence. The overall result is obtained by putting together all of the remaining nodes, following the generic semantics for filters.

The self axis just returns the context node.


dynEnv |- self:: on NodeValue => NodeValue

The child, parent, attribute and namespace axis are implemented through their corresponding accessors in the [XQuery 1.0 and XPath 2.0 Data Model].


dynEnv |- child:: on NodeValue => dm:children(NodeValue)


dynEnv |- attribute:: on NodeValue => dm:attributes(NodeValue)


dynEnv |- parent:: on 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 |- child:: on NodeValue => Value1
dynEnv |- descendant:: on Value1 => Value2

dynEnv |- descendant:: on NodeValue => fs:distinct-doc-order(op:concatenate(Value1, Value2))

dynEnv |- self:: on NodeValue => Value1
dynEnv |- descendant:: on Value1 => Value2

dynEnv |- descendant-or-self:: on NodeValue => op:concatenate(Value1, Value2)

dynEnv |- parent:: on NodeValue => Value1
dynEnv |- ancestor:: on Value1 => Value2

dynEnv |- ancestor:: on NodeValue => op:concatenate(Value1, Value2)

dynEnv |- self:: on NodeValue => Value1
dynEnv |- ancestor:: on Value1 => Value2

dynEnv |- ancestor-or-self:: on NodeValue => op:concatenate(Value1, Value2)

In all the other cases, the filter application results in an empty sequence.

dynEnv |- AxisName:: on NodeValue => () otherwise.

Ed. Note: Peter: Generally steps may operate on nodes and values alike; the axis rules only can operate on nodes (NodeValue). Is it a dynamic error to apply an axis rule on a value? See [Issue-0125:  Operations on node only in XPath].

5.2.1.2 Node Tests

Introduction

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

[65 (XQuery)]   NodeTest   ::=   KindTest |  NameTest
[66 (XQuery)]   NameTest   ::=   QName |  Wildcard
[67 (XQuery)]   Wildcard   ::=   "*" |  <NCName ":" "*"> |  <"*" ":" NCName>
[68 (XQuery)]   KindTest   ::=   ProcessingInstructionTest
|  CommentTest
|  TextTest
|  AnyKindTest
[69 (XQuery)]   ProcessingInstructionTest   ::=   <"processing-instruction" "("> StringLiteral? ")"
[70 (XQuery)]   CommentTest   ::=   <"comment" "("> ")"
[71 (XQuery)]   TextTest   ::=   <"text" "("> ")"
[72 (XQuery)]   AnyKindTest   ::=   <"node" "("> ")"

Core Grammar

The core grammars productions for XPath node tests are:

[44 (Core)]   NodeTest   ::=   KindTest |  NameTest
[45 (Core)]   NameTest   ::=   QName |  Wildcard
[46 (Core)]   Wildcard   ::=   "*" |  <NCName ":" "*"> |  <"*" ":" NCName>
[47 (Core)]   KindTest   ::=   ProcessingInstructionTest
|  CommentTest
|  TextTest
|  AnyKindTest
[48 (Core)]   ProcessingInstructionTest   ::=   <"processing-instruction" "("> StringLiteral? ")"
[49 (Core)]   CommentTest   ::=   <"comment" "("> ")"
[50 (Core)]   TextTest   ::=   <"text" "("> ")"
[51 (Core)]   AnyKindTest   ::=   <"node" "("> ")"

Static Type Analysis

The following typing rules apply to filters that are node tests in the context of a principal node kind.

Node tests on elements and attributes always accomplish the most specific type possible. For example, if $v is bound to an element with a computed name, the type of $v is element { Type }. The static type computed for the expression $v/self::foo is element foo {Type}, which makes use of the nametest foo to arrive at a more specific type. Also note that each case of name matching restricts the principal node kind to the appropriate one.

Ed. Note: [Kristoffer/XSL] Perhaps use statEnv |- expand(QName) = qname(URI, ncname) instead of qname = prefix:local? Also The ElemOrAttrType doesn't allow wildcard in the ElementName or AttributeName, so either the rules can be removed or the definition should be updated.

QName2 = Prefix2:LocalPart2
fn:get-namespace-uri( QName1) = statEnv.namespace(Prefix2)
fn:get-local-name( QName1 ) = LocalPart2

statEnv |- element, QName2 on element QName1 {Type} : element QName1 {Type}

QName2 = Prefix2:LocalPart2
LocalPart1 = LocalPart2

statEnv |- element, QName2 on element *:LocalPart1 {Type} : element QName2 {Type}

QName2 = Prefix2:LocalPart2
statEnv.namespace(Prefix1) = statEnv.namespace(Prefix2)

statEnv |- element, QName2 on element Prefix1:* {Type} : element Prefix1:LocalPart2{Type}


statEnv |- element, QName2 on element {Type} : element QName2 {Type}

fn:get-local-name( QName1 ) = LocalPart2

statEnv |- element, *:LocalPart2 on element QName1 {Type} : element QName1 {Type}

LocalPart1 = LocalPart2

statEnv |- element, *:LocalPart2 on element *:LocalPart1 {Type} : element *:LocalPart2 {Type}


statEnv |- element, *:LocalPart2 on element Prefix1:* {Type} : element Prefix1:LocalPart2{Type}


statEnv |- element, *:LocalPart2 on element { Type } : element *:LocalPart2 {Type}

fn:get-namespace-uri( QName1) = statEnv.namespace(Prefix2)

statEnv |- element, Prefix2:* on element QName1 {Type} : element QName1 {Type}


statEnv |- element, Prefix2:* on element *:LocalPart1 {Type} : element Prefix2:LocalPart1 {Type}

statEnv.namespace(Prefix1) = statEnv.namespace(Prefix2)

statEnv |- element, Prefix2:* onelement Prefix1:* {Type} : element Prefix1:* {Type}


statEnv |- element, Prefix2:* on element {Type} : element Prefix2:* {Type}


statEnv |- element, * on element prefix:local {Type} : element prefix:local {Type}

Very similar typing rules apply to attributes:

QName2 = Prefix2:LocalPart2
fn:get-namespace-uri( QName1) = statEnv.namespace(Prefix2)
fn:get-local-name( QName1 ) = LocalPart2

statEnv |- attribute, QName2 on attribute QName1 {Type} : attribute QName1 {Type}

QName2 = Prefix2:LocalPart2
LocalPart1 = LocalPart2

statEnv |- attribute, QName2 on attribute *:LocalPart1 {Type} : attribute QName2 {Type}

QName2 = Prefix2:LocalPart2
statEnv.namespace(Prefix1) = statEnv.namespace(Prefix2)

statEnv |- attribute, QName2 on attribute Prefix1:* {Type} : attribute Prefix1:LocalPart2{Type}


statEnv |- attribute, QName2 on attribute {Type} : attribute QName2 {Type}

fn:get-local-name( QName1 ) = LocalPart2

statEnv |- attribute, *:LocalPart2 on attribute QName1 {Type} : attribute QName1 {Type}

LocalPart1 = LocalPart2

statEnv |- attribute, *:LocalPart2 on attribute *:LocalPart1 {Type} : attribute *:LocalPart2 {Type}


statEnv |- attribute, *:LocalPart2 on attribute Prefix1:* {Type} : attribute Prefix1:LocalPart2{Type}


statEnv |- attribute, *:LocalPart2 on attribute {Type} : attribute *:LocalPart2 {Type}

fn:get-namespace-uri( QName1) = statEnv.namespace(Prefix2)

statEnv |- attribute, Prefix2:* on attribute QName1 {Type} : attribute QName1 {Type}


statEnv |- attribute, Prefix2:* on attribute *:LocalPart1 {Type} : attribute Prefix2:LocalPart1 {Type}

statEnv.namespace(Prefix1) = statEnv.namespace(Prefix2)

statEnv |- attribute, Prefix2:* on attribute Prefix1:* {Type} : attribute Prefix1:* {Type}


statEnv |- attribute, Prefix2:* on attribute {Type} : attribute Prefix2:* {Type}


statEnv |- attribute, * on attribute prefix:local {Type} : attribute prefix:local {Type}

Comments, processing instructions, and text:


statEnv |- PrincipalNodeKind, processing-instruction() on processing-instruction : processing-instruction


statEnv |- PrincipalNodeKind, processing-instruction(String) on processing-instruction : processing-instruction


statEnv |- PrincipalNodeKind, comment() on comment : comment


statEnv |- PrincipalNodeKind, text() on text : text


statEnv |- PrincipalNodeKind, node() on NodeType : NodeType

If none of the above rules apply, then the node test returns the empty sequence and the following dynamic rule is applied:

statEnv |- PrincipalNodeKind, node() on NodeType : ()

Ed. Note: Peter: Except for self::, all axes guarantee that the NodeType is not the generic type node. However, when the type node is encountered, it has to be interpreted as element | attribute | text | comment | processing-instruction for these typing rules to work.

Dynamic Evaluation

The dynamic semantics indicates for each node test whether a node is retained.

dm:node-kind( NodeValue ) = PrincipalNodeKind
dm:name( NodeValue ) = QName1
QName2 = Prefix2:LocalPart2
fn:get-namespace-uri ( QName1 ) = statEnv.namespace(Prefix2)
fn:get-local-name ( QName1 ) = LocalPart2

dynEnv |- PrincipalNodeKind, QName2 on NodeValue => NodeValue

dm:node-kind( NodeValue ) = PrincipalNodeKind
dm:name ( NodeValue ) = qname

dynEnv |- PrincipalNodeKind, * on NodeValue => NodeValue

dm:node-kind( NodeValue ) = PrincipalNodeKind
dm:name ( NodeValue ) = qname
fn:get-namespace-uri ( qname ) = statEnv.namespace(prefix)

dynEnv |- PrincipalNodeKind, prefix:* on NodeValue => NodeValue

dm:node-kind( NodeValue ) = PrincipalNodeKind
dm:name ( NodeValue ) = qname
fn:get-local-name ( qname ) = local

dynEnv |- PrincipalNodeKind, *:local on NodeValue => NodeValue

dm:node-kind ( NodeValue ) = "processing-instruction"

dynEnv |- PrincipalNodeKind, processing-instruction() on NodeValue => NodeValue

dm:node-kind ( NodeValue ) = "processing-instruction"
dm:name ( NodeValue ) = qname
fn:get-local-name ( qname ) = String

dynEnv |- PrincipalNodeKind, processing-instruction( String ) on NodeValue => NodeValue

Ed. Note: Note the use of the fn:get-local-name function to extract the local name out of the name of the node.

dm:node-kind ( NodeValue ) = "comment"

dynEnv |- PrincipalNodeKind, comment() on NodeValue => NodeValue

dm:node-kind ( NodeValue ) = "text"

dynEnv |- PrincipalNodeKind, text() on NodeValue => 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 |- PrincipalNodeKind, node() on NodeValue => NodeValue

If none of the above rules applies then the node test returns the empty sequence, and the following dynamic rule is applied:

dynEnv |- PrincipalNodeKind, node() on NodeValue => ()

5.2.2 Predicates

Introduction

Predicates are composed of zero or more expressions enclosed in square brackets.

[77 (XQuery)]   Predicates   ::=   ("[" Expr "]")*

Normalization

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

 
[Expr]Predicates
==
typeswitch (Expr)
  case $v as numeric return op:numeric-equal($v, $fs:position)
  default $v return fn:boolean($v)

Note that the semantics of predicates whose parameter is a numeric value also works for other numeric than integer values, in which case the op:numeric-equal returns false when compared to a position. For example the expression //a[3.4] is allowed and always returns the empty sequence)

Ed. Note: Issue: The static semantics for the case where the parameter of a predicate is a numeric value is still an open issue. See [Issue-0011:  XPath tumbler syntax instead of index?].

5.2.3 Unabbreviated Syntax

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

5.2.4 Abbreviated Syntax

[75 (XQuery)]   AbbreviatedForwardStep   ::=   "." |  ("@" NameTest) |  NodeTest
[76 (XQuery)]   AbbreviatedReverseStep   ::=   ".."

Normalization

Here are normalization rules for the abbreviated syntax.

 
[ // RelativePathExpr ]Expr
==
[ / descendant-or-self::node() / RelativePathExpr]Expr
 
[ StepExpr1 // StepExpr2 ]Expr
==
[StepExpr1 / descendant-or-self::node() / StepExpr2]Expr
 
[ . ]Expr
==
$fs:dot
 
[ .. ]Expr
==
parent::node()
 
[ @ NameTest ]Expr
==
attribute :: NameTest
 
[ NodeTest ]Expr
==
child :: NodeTest

5.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.

5.3.1 Constructing Sequences

[24 (XQuery)]   ExprSequence   ::=   Expr ("," Expr)*
[35 (XQuery)]   RangeExpr   ::=   AdditiveExpr ( "to"  AdditiveExpr )?

Normalization

The sequence expression is normalized into a sequence of core expressions:

 
["(" ExprSequence ")"]Expr
==
"(" [ ExprSequence ]Expr ")"
 
[Expr1 , ... , Exprn]Expr
==
[Expr1]Expr, ..., [Exprn]Expr

Ed. Note: Mike Kay remarks that it would be cleaner to have binary rules and recursion to define the semantics rather than the ... notation.

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

 
[Expr1 to Expr2]Expr
==
op:to ([Expr1],[Expr2]Expr)

Core Grammar

The core grammar rule for sequence expressions is:

[21 (Core)]   ExprSequence   ::=   Expr ("," Expr)*

Static Type Analysis

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

statEnv |- Expr1 : Type1      ...     statEnv |- Exprn : Typen

statEnv |- Expr1 , ... , Exprn : Type1, ..., Typen

Dynamic Evaluation

The dynamic semantics of the sequence expression follows. Each expression in the sequence is evaluated and the resulting values are concatenated into one sequence.

dynEnv |- Expr1 => Value1     dynEnv |- Expr2 => Value2     ...     dynEnv |- Exprn => Valuen

dynEnv |- Expr1, ..., Exprn => op:concatenate(Value1, op:concatenate(Value2, op:concatenate(... , Valuen) ) )

Normalization

The normalization of the infix "to" operator maps it into an application of op:to.

 
[Expr1 "op:to" Expr2]Expr
==
[op:to (Expr1, Expr2)]Expr

Static Type Analysis

The static semantics of the op:to function is defined in [7 Additional Semantics of Functions].

Dynamic Evaluation

The dynamic semantics rules for function calls given in [5.1.4 Function Calls] are applied to the function call op:to above.

Ed. Note: Should the "to" operator be defined formally? See [Issue-0133:  Should to also be described in the formal semantics?].

5.3.2 Combining Sequences

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

[39 (XQuery)]   UnionExpr   ::=   IntersectExceptExpr ( ("union" |  "|")  IntersectExceptExpr )*
[40 (XQuery)]   IntersectExceptExpr   ::=   ValueExpr ( ("intersect" |  "except")  ValueExpr )*

Notation

First, a union, intersect, or except expression is normalized into a corresponding core expression. The mapping function []SequenceOp is defined by the following tables:

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

Normalization

 
[Expr1 SequenceOp Expr2]Expr
==
[SequenceOp]SequenceOp ( [Expr1]Expr, [Expr2]Expr )

Static Type Analysis

The static semantics of the functions that operate on sequences are defined in [7 Additional Semantics of Functions].

Dynamic Evaluation

The dynamic semantics rules for function calls given in [5.1.4 Function Calls] are applied to the calls to functions on sequences above.

5.4 Arithmetic Expressions

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

[36 (XQuery)]   AdditiveExpr   ::=   MultiplicativeExpr ( ("+" |  "-")  MultiplicativeExpr )*
[37 (XQuery)]   MultiplicativeExpr   ::=   UnaryExpr ( ("*" |  "div" |  "idiv" |  "mod")  UnaryExpr )*
[38 (XQuery)]   UnaryExpr   ::=   ("-" |  "+")* UnionExpr
[41 (XQuery)]   ValueExpr   ::=   ValidateExpr |  CastExpr |  TreatExpr |  Constructor |  PathExpr
[37 (XPath)]   ValueExpr   ::=   ValidateExpr |  CastExpr |  TreatExpr |  PathExpr

Notation

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

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

Core Grammar

All of those expressions are normalized to the following core grammar production:

[28 (Core)]   ValueExpr   ::=   ValidateExpr |  CastExpr |  Constructor |  StepExpr

Normalization

The normalization rules for the arithmetic operators first apply atomization to each argument and bind these values to variables. The type declarations on the let variables assert that the result of atomizing the arguments is the empty sequence or one atomic value. If either atomized argument is the empty sequence, the expression evaluates to the empty sequence. Otherwise, the overloaded internal function corresponding the the arithmetic operator is applied. The table above maps the operators to the appropriate internal function. The mapping from the overloaded internal functions to the corresponding monomorphic function is given in [B Mapping of Overloaded Internal Functions].

 
[Expr1 ArithOp Expr2]Expr
==
let atomic value? $e1 := [Expr1]Atomize return
let atomic value? $e2 := [Expr2]Atomize return
   typeswitch ($e1)
   case $v as empty return ()
   default $v1
     typeswitch ($e2)
     case $v as empty return ()
     default $v2 return [ArithOp]ArithOp ($v1, $v2))

Ed. Note: Mary: Casting from untyped to double not implemented. Current (function call) semantics will always attempt to promote an untyped value to the numeric type of the other argument, instead of directly to double. See [Issue-0177:  Coercion between untyped and atomic values].

The unary operators are mapped similarly.

 
[+ Expr]Expr
==
let atomic value? $e := [Expr]Atomize return
   typeswitch ($e)
   case $v as empty return ()
   default $v return fs:plus(0, $v))
 
[- Expr]Expr
==
let atomic value? $e := [Expr]Atomize return
   typeswitch ($e)
   case $v as empty return ()
   default $v return fs:minus (0, $v))

Ed. Note: XPath 1.0 compatibility: Rules for converting function arguments of arithmetic operators not implemented yet. See [Issue-0178:  Semantics of XPath 1.0 compatibility].

Ed. Note: XPath 1.0 backwards compatibility not yet incorporated. See [Issue-0178:  Semantics of XPath 1.0 compatibility].

Core Grammar

There are no core grammar rules for arithmetic expressions as they are normalized to function calls.

Static Type Analysis

There are no static typing rules for arithmetic expressions as they are normalized to core function calls.

Dynamic Evaluation

The normalization rules map all arithmetic operators into core expressions, whose dynamic semantics is defined in other sections. Therefore, there are no dynamic semantics rules for arithmetic operators. The dynamic semantics rules for function calls given in [5.1.4 Function Calls] apply to all the function calls.

5.5 Comparison Expressions

Introduction

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

[34 (XQuery)]   ComparisonExpr   ::=   RangeExpr ( (ValueComp
|  GeneralComp
|  NodeComp
|  OrderComp)  RangeExpr )?
[54 (XQuery)]   ValueComp   ::=   "eq" |  "ne" |  "lt" |  "le" |  "gt" |  "ge"
[53 (XQuery)]   GeneralComp   ::=   "=" |  "!=" |  "<" |  "<=" |  ">" |  ">="
[55 (XQuery)]   NodeComp   ::=   "is" |  "isnot"
[56 (XQuery)]   OrderComp   ::=   "<<" |  ">>"

5.5.1 Value Comparisons

Notation

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

ValueOp[ValueOp]ValueOp
"eq"fs:eq
"ne"fs:ne
"lt"fs:lt
"le"fs:le
"gt"fs:gt
"ge"fs:ge

Normalization

The normalization rules for the value comparison operators first apply atomization to each argument and bind these values to variables. The type declarations on the let variables assert that the result of atomizing the arguments is the empty sequence or one atomic value. If either atomized argument is the empty sequence, the expression evaluates to the empty sequence. Otherwise, the overloaded internal function corresponding the the value comparison operator is applied. The table above maps the operators to the appropriate internal function. The mapping from the overloaded internal functions to the corresponding monomorphic function is given in [B Mapping of Overloaded Internal Functions].

 
[Expr1 ValueOp Expr2]Expr
==
let atomic value? $e1 := [Expr1]Atomize return
let atomic value? $e2 := [Expr2]Atomize return
   typeswitch ($e1)
   case $v as empty return ()
   default $v1
     typeswitch ($e2)
     case $v as empty return ()
     default $v2 return [ValueOp]ValueOp ($v1, $v2))

Core Grammar

There are no core grammar rules for value comparisons as they are normalized to function calls.

Static Type Analysis

There are no static type rules for the value comparison operators as they are normalized to function calls. As it were, they all have return type xs:boolean, as specified in [XQuery 1.0 and XPath 2.0 Functions and Operators].

Dynamic Evaluation

The normalization rules map all value comparison operators into core expressions, therefore, there are no dynamic semantics rules for value comparison operators. The dynamic semantics rules for function calls given in [5.1.4 Function Calls] apply to all the function calls.

5.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

For convenience, GeneralOp denotes the operators "=", "!=", "<", "<=", ">", or ">=".

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

GeneralOp[GeneralOp]GeneralOp
"=""eq"
"!=""ne"
"<""lt"
"<=""le"
">""gt"
">=""ge"

Normalization

A general comparison expression is normalized by mapping it into an existentially quantified, value-comparison expression, which is normalized recursively.

 
[Expr1 GeneralOp Expr2]Expr
==
[some $v1 in Expr1 satisfies (some $v2 in Expr2 satisfies $v1 [GeneralOp]GeneralOp $v2)]Expr

Ed. Note: XPath 1.0 backwards compatibility not yet incorporated.See [Issue-0178:  Semantics of XPath 1.0 compatibility].

Core Grammar

There are no core grammar rules for general comparisons as they are normalized to existentially quantified core expressions.

Static Type Analysis

There are no static type rules for the general comparison operators. The existentially quantified "some" expression always returns xs:boolean. Its static typing semantics is given in [5.11 Quantified Expressions].

Dynamic Evaluation

The normalization rules map all general comparison operators into core expressions, whose dynamic semantics is defined in other sections. Therefore, there are no dynamic semantics rules for general comparison operators.

5.5.3 Node Comparisons

Normalization

The normalization rules for node comparisons map each argument expression and bind these values to variables. The type declarations on the let variables assert that each value is the empty sequence or one node value. If either argument is the empty sequence, the expression evaluates to the empty sequence. Otherwise, the appropriate node comparison function is applied.

 
[Expr1 is Expr2]Expr
==
let node? $e1 := [Expr1]Expr return
let node? $e2 := [Expr2]Expr return
   typeswitch ($e1)
   case $v as empty return ()
   default $v1
     typeswitch ($e2)
     case $v as empty return ()
     default $v2 return op:node-equal($v1, $v2)
 
[Expr1 isnot Expr2]Expr
==
let node? $e1 := [Expr1]Expr return
let node? $e2 := [Expr2]Expr return
   typeswitch ($e1)
   case $v as empty return ()
   default $v1
     typeswitch ($e2)
     case $v as empty return ()
     default $v2 return fn:not(op:node-equal($v1, $v2))

Core Grammar

There are no core grammar rules for node comparisons as they are normalized to function calls.

Static Type Analysis

There are no static type rules for the node comparison operators.

Dynamic Evaluation

The normalization rules map the node comparison operators into core expressions, whose dynamic semantics is defined in other sections. Therefore, there are no dynamic semantics rules for node comparison operators.

5.5.4 Order Comparisons

Normalization

The normalization rules for order comparisons map each argument expression and bind these values to variables. The type declarations on the let variables assert that each value is the empty sequence or one node value. If either argument is the empty sequence, the expression evaluates to the empty sequence. Otherwise, the appropriate order comparison function is applied.

 
[Expr1 << Expr2]Expr
==
let node? $e1 := [Expr1]Expr return
let node? $e2 := [Expr2]Expr return
   typeswitch ($e1)
   case $v as empty return ()
   default $v1
     typeswitch ($e2)
     case $v as empty return ()
     default $v2 return fn:node-before($v1, $v2))
 
[Expr1 >> Expr2]Expr
==
let node? $e1 := [Expr1]Expr return
let node? $e2 := [Expr2]Expr return
   typeswitch ($e1)
   case $v as empty return ()
   default $v1
     typeswitch ($e2)
     case $v as empty return ()
     default $v2 return fn:node-after($v1, $v2))

Core Grammar

There are no core grammar rules for order comparisons as they are normalized to function calls.

Static Type Analysis

There are no static type rules for the order comparison operators.

Dynamic Evaluation

The normalization rules map the order comparison operators into core expressions, whose dynamic semantics is defined in other sections. Therefore, there are no dynamic semantics rules for order comparison operators.

5.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.

[26 (XQuery)]   OrExpr   ::=   AndExpr ( "or"  AndExpr )*
[27 (XQuery)]   AndExpr   ::=   FLWRExpr ( "and"  FLWRExpr )*

Normalization

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

 
[Expr1 and Expr2]Expr
==
fn:empty( for $fs:item in ( [[Expr1]Expr]Effective_Boolean_Value , [[Expr2]Expr]Effective_Boolean_Value ) return if ($fs:item) then () else 1)
 
[Expr1 or Expr2]Expr
==
fn:exists( for $fs:item in ( [[Expr1]Expr]Effective_Boolean_Value , [[Expr2]Expr]Effective_Boolean_Value ) return if ($fs:item) then 1 else ())

Ed. Note: Note that the non-determinism in the semantics of quantified expressions is not modeled here. See [Issue-0136:  Non-determinism in the semantics].

Core Grammar

There are no core grammar rules for logical expressions which normalized to other kinds of [XPath/XQuery] expressions.

Static Type Analysis

There are no static type rules for the logical comparison operators. They both have return type xs:boolean, as specified in [XQuery 1.0 and XPath 2.0 Functions and Operators].

Dynamic Evaluation

The normalization rules map the logical comparison operators into core expressions, whose dynamic semantics is defined in other sections. Therefore, there are no dynamic semantics rules for logical comparison operators.

Notice that the conditional operators are non-deterministic because for is.

5.7 Constructors

Ed. Note: Status:This section is still awaiting further revision related to the semantics of element construction and validation. See [Issue-0166:  Static typing for validate] and [Issue-0170:  Imprecise static type of constructed elements].

[XPath/XQuery] supports two forms of constructors: a "literal" form that follows the XML syntax, and element and attribute constructors that can be used to construct stand-alone elements and attributes, possibly with a computed name.

[52 (XQuery)]   Constructor   ::=   ElementConstructor
|  XmlComment
|  XmlProcessingInstruction
|  CdataSection
|  ComputedDocumentConstructor
|  ComputedElementConstructor
|  ComputedAttributeConstructor
|  ComputedTextConstructor
[94 (XQuery)]   ElementConstructor   ::=   ( |  "<") QName AttributeList ("/>" |  (">" ElementContent* "</" QName S? ">"))
[102 (XQuery)]   ElementContent   ::=   Char
|  "{{"
|  "}}"
|  ElementConstructor
|  EnclosedExpr
|  CdataSection
|  CharRef
|  PredefinedEntityRef
|  XmlComment
|  XmlProcessingInstruction
[103 (XQuery)]   AttributeList   ::=   (S (QName S? "=" S? AttributeValue)?)*
[104 (XQuery)]   AttributeValue   ::=   (["] (EscapeQuot |  AttributeValueContent)* ["])
|  (['] (EscapeApos |  AttributeValueContent)* ['])
[105 (XQuery)]   AttributeValueContent   ::=   Char
|  CharRef
|  "{{"
|  "}}"
|  EnclosedExpr
|  PredefinedEntityRef
[106 (XQuery)]   EnclosedExpr   ::=   ( |  "{") ExprSequence "}"

Core Grammar

The core grammar productions for constructors are:

[35 (Core)]   Constructor   ::=   XmlComment
|  XmlProcessingInstruction
|  ComputedDocumentConstructor
|  ComputedElementConstructor
|  ComputedAttributeConstructor
|  ComputedTextConstructor
[77 (Core)]   EnclosedExpr   ::=   ( |  "{") ExprSequence "}"

5.7.1 Element Constructors

Introduction

[102 (XQuery)]   ElementContent   ::=   Char
|  "{{"
|  "}}"
|  ElementConstructor
|  EnclosedExpr
|  CdataSection
|  CharRef
|  PredefinedEntityRef
|  XmlComment
|  XmlProcessingInstruction

The static and dynamic semantics of the literal forms of element constructors is obtained after normalization to computed element constructors.

Notation

The auxiliary mapping rules []ElementContent and []AttributeContent are used for the normalization of element and attribute content respectively.

Normalization

Literal characters, escaped curly braces, character references, and predefined entity references in element content are treated specially. This normalization rule assumes:

  1. that the significant whitespace characters in element constructors have been preserved, as described in [5.7.3 Whitespace in Constructors];

  2. that character references have been resolved to individual characters and predefined entity references have been resolved to sequences of characters, and

  3. that the rule is applied to the longest contiguous sequence of characters.

The following normalization rules take the longest consecutive sequence of individual characters that arise from literal characters, escaped curly braces, character references, and predefined entity references and normalizes the character sequence as a text node.

 
[Char*]ElementContent
==
dm:text-node(fs:characters_to_string(Char*))

We start with the rules for normalizing a literal XML element's content. We normalize each individual value and construct a sequence of the normalized values. Consecutive sequences of characters are normalized as a unit, applying the rule above.

 
[ ElementContent0 ..., ElementContentn ]ElementContent
==
([ ElementContent0 ]ElementContent , ..., [ ElementContentn]ElementContent)

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

 
[ { Expr0, ..., Exprn } ]ElementContent
==
([ Expr0 ]Expr , ..., [ Exprn]Expr, dm:text-node(""))

We need to distinguish between multiple enclosed expressions, because the rule for converting sequences of atomic values into strings are applied to sequences within distinct enclosed expressions. To distinguish between multiple enclosed expressions, we add an empty text node to the end of the constructed sequence above -- this empty text node is eliminated in the dynamic evaluation rule 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.

Processing instructions and comments in element content are normalized by applying the standard normalization rules.

 
[XmlProcessingInstruction]ElementContent
==
[XmlProcessingInstruction]Expr
 
[XmlComment]ElementContent
==
[XmlComment]Expr

The following rules normalize the two forms of literal XML element constructors by normalizing their name, attribute list, and element content and translates the normalized values into the corresponding computed element constructor.

[94 (XQuery)]   ElementConstructor   ::=   ( |  "<") QName AttributeList ("/>" |  (">" ElementContent* "</" QName S? ">"))
 
[ < QName AttributeList > ElementContent* </ QName S? > ]Expr
==
element [QName]{ [ AttributeList ]AttributeContent , [ ElementContent* ]ElementContent }
 
[ < QName AttributeList /> ]Expr
==
element [QName]{ [ AttributeList ]AttributeContent }

Like literal XML element constructors, literal XML attribute constructors are normalized to computed attribute constructors.

[103 (XQuery)]   AttributeList   ::=   (S (QName S? "=" S? AttributeValue)?)*
[104 (XQuery)]   AttributeValue   ::=   (["] (EscapeQuot |  AttributeValueContent)* ["])
|  (['] (EscapeApos |  AttributeValueContent)* ['])
[105 (XQuery)]   AttributeValueContent   ::=   Char
|  CharRef
|  "{{"
|  "}}"
|  EnclosedExpr
|  PredefinedEntityRef

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:

  1. 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 arise from literal characters, escaped curly braces, character references, predefined entity references, and escaped single and double quotes and normalizes the character sequence as a string.

 
[Char*]AttributeContent
==
fs:characters_to_string(Char*)

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

 
[ { Expr0, ..., Exprn } ]AttributeContent
==
([ Expr0 ]Expr , ..., [ Exprn]Expr, dm:text-node(""))

As in literal XML elements, we need to distinguish between multiple enclosed expressions in attribute content, because the rule for converting sequences of atomic values into strings are applied to sequences within distinct enclosed expressions. As in element content, to distinguish between multiple enclosed expressions in attribute content, we add an empty text node to the end of the constructed sequence above -- this empty text node is eliminated in the dynamic evaluation rule.

We normalize an AttributeValue (a literal attribute's value) by normalizing each individual value in its content and then construct a sequence of the normalized values. Consecutive sequences of characters are normalized as a unit, applying the rules above.

 
[ AttributeValueContent0 ..., AttributeValueContentn ]AttributeContent
==
([ AttributeValueContent0 ]AttributeContent , ..., [ AttributeValueContentn]AttributeContent)

An AttributeList 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.

 
[
QName0 S? = S? (AttributeValue0 | EnclosedExpr0) ...
QNamen S? = S? (AttributeValuen | EnclosedExprn) ...
]
==
(attribute [QName0] { [ (AttributeValue0 | EnclosedExpr0) ]AttributeContent},
...,
attribute [QNamen] { [ (AttributeValuen | EnclosedExprn) ]AttributeContent})

Core Grammar

There are no core grammar rules for literal XML element or attribute constructors as they are normalized to computed constructors.

Static Type Analysis

There are no additional static type rules for literal XML element or attribute constructors.

Dynamic Evaluation

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

5.7.2 Computed Element and Attribute Constructors

[95 (XQuery)]   ComputedDocumentConstructor   ::=   <"document" "{"> ExprSequence "}"
[96 (XQuery)]   ComputedElementConstructor   ::=   (<"element" QName "{"> |  (<"element" "{"> Expr "}" "{")) ExprSequence? "}"
[97 (XQuery)]   ComputedAttributeConstructor   ::=   (<"attribute" QName "{"> |  (<"attribute" "{"> Expr "}" "{")) ExprSequence? "}"
[98 (XQuery)]   ComputedTextConstructor   ::=   <"text" "{"> ExprSequence? "}"
5.7.2.1 Computed Text Nodes

Normalization

A text node constructor contains an expression, which must evaluate to an xs:string value.

 
[text { Expr }]Expr
==
text { [Expr]Expr }

Static Type Analysis

The static semantics checks that the argument expression has type xs:string. The type of the entire expression is simply the text node type.

statEnv |- Expr : xs:string

statEnv |- text { Expr } : text

Dynamic Evaluation

The dynamic semantics checks that the argument expression evaluates a value that has type xs:string. The entire expression evaluates to a new text node by applying the text node constructor dm:text-node.

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

statEnv |- text { Expr } => dm:text-node ( Value )

5.7.2.2 Computed Document Nodes

Normalization

A document node constructor contains an expression, which must evaluate to a sequence of element nodes.

 
[document { Expr }]Expr
==
document { [Expr]Expr }

Static Type Analysis

The static semantics checks that the argument expression has type sequence of elements. The type of the entire expression is simply the document node type.

statEnv |- Expr : element*

statEnv |- document { Expr } : document

Dynamic Evaluation

The dynamic semantics checks that the argument expression evaluates a value that has type element*. The entire expression evaluates to a new document node by applying the text node constructor .

dynEnv |- Expr => Value      dynEnv |- Value matches element*

statEnv |- document { Expr } => ( Value )

5.7.2.3 Computed Element Nodes

An element constructor may contain an arbitrary sequence of items, e.g., atomic values, attributes, and child elements. Here's an element constructor that contains an integer, an element, a string, and an attribute:

element address { 123, element street {"Roosevelt Ave."},
"Flushing, NY", attribute zip { "11368" } }

Normalization

Computed element constructors are normalized by mapping their name and expression sequence. The normalization rule partitions attribute nodes from other nodes and atomic values in the element content.

 
[element QName { ExprSequence }]Expr
==
let $e := [ExprSequence]Expr return
let $attributes := for $fs:new in $e return
     typeswitch $fs:new
     case $a as attribute return $a
     default return ()
let $everythingelse := for $fs:new in $e return
     typeswitch $fs:new
     case $a as attribute return ()
     default $v return $v
return
   element [QName] { $attributes, $everythingelse }

When the name of an element is computed, the normalization rule also checks that the value of the element's name is a xs:QName.

 
[element { Expr } { ExprSequence }]Expr
==
let $name as xs:QName := [Expr]Expr return
let $e := [ExprSequence]Expr return
let $attributes := for $fs:new in $e return
     typeswitch $fs:new
     case $a as attribute return $a
     default return ()
let $everythingelse := for $fs:new in $e return
     typeswitch $fs:new
     case $a as attribute return ()
     default $v return $v
return
   element { $name } { $attributes, $everythingelse }
5.7.2.4 Constructed Attribute Nodes

Normalization

Computed attribute expressions are normalized by mapping their sub-expressions.

 
[attribute QName { ExprSequence }]Expr
==
attribute [QName]Expr { [ExprSequence]Expr }
 
[attribute { Expr } { ExprSequence }]Expr
==
let $name as xs:QName := [Expr]Expr return
attribute { $name } { [ExprSequence]Expr }

Core Grammar

The core grammar rules for computed constructors are:

[71 (Core)]   ComputedElementConstructor   ::=   (<"element" QName "{"> |  (<"element" "{"> Expr "}" "{")) ExprSequence? "}"
[72 (Core)]   ComputedAttributeConstructor   ::=   (<"attribute" QName "{"> |  (<"attribute" "{"> Expr "}" "{")) ExprSequence? "}"
[70 (Core)]   ComputedDocumentConstructor   ::=   <"document" "{"> ExprSequence "}"
[73 (Core)]   ComputedTextConstructor   ::=   <"text" "{"> ExprSequence? "}"

Static Type Analysis

The normalization rules leave us with only the operator form of the element or attribute constructor to handle. The element (attribute) operator still has two forms: one in which a QName is supplied as the element (attribute) name, and the other in which a computed expression is supplied. In the latter case, the name cannot be known until runtime, and the element (attribute) is given a wildcard type.

Note that the static type for constructed elements and attributes is very poor as the static type of their content is lost during construction. A possible solution is to implicitly validate when the element is constructed. See [Issue-0169:  Conformance Levels] for suggestions.

statEnv |- expand(QName) = qname

statEnv |- element QName { ExprSequence } : element qname { xs:anyType }

statEnv |- Expr : xs:QName

statEnv |- element { Expr } { ExprSequence } : element { xs:anyType }

statEnv |- Expr : xs:QName

statEnv |- attribute { Expr } { ExprSequence } : attribute { xs:anySimpleType }

statEnv |- expand(QName) = qname

statEnv |- attribute QName { ExprSequence } : attribute qname { xs:anySimpleType }

Ed. Note: DD: the above is a necessary consequence of our current evaluation model. One variation that I can think of is that the static rules could try looking up the element name in element environment. If the element name is found, then the associated, named type is used (and the contents are required to match). If the named element type is not found, then the constructed type is used, as before. Thus, in this scenario, validation would be done whenever an element with a "global" name was created. See also comments on the impact of (non-)validation on element construction, in the next section.

Dynamic Evaluation

The following rules construct an element from its name and content. The earlier normalization rule guarantees that all attributes precede other element content, which is a sequence of node and atomic values. Section [3.7.4 Data Model Representation] in [XQuery 1.0: A Query Language for XML] specifies the rules for converting a sequence of atomic values into a text node prior to element construction. As formal specification of these conversion rules is not instructive, the function [7.1.3 The fs:item-sequence-to-node-sequence function] implements this conversion.

dynEnv |- QName => qname
dynEnv |- ExprSequence => ( AttributeValues, Items )

dynEnv |- element QName { ExprSequence } =>
       dm:element-node(qname,
dm:empty-sequence(),
AttributeValues,
fs:item-sequence-to-node-sequence(Items)
xs:anyType)

dynEnv |- Expr => qname
dynEnv |- ExprSequence => ( AttributeValues, Items )

dynEnv |- element { Expr } { ExprSequence } =>
       dm:element-node(qname,
dm:empty-sequence(),
AttributeValues,
fs:item-sequence-to-node-sequence(Items)
xs:anyType)

Note that the element constructor dm:element-node makes copies of any nodes in its arguments; therefore the result of element construction is a completely "new" element.

The following rules construct an attribute from its name and values and are similar to those for elements. Section [3.7.2 Data Model Representation] in [XQuery 1.0: A Query Language for XML] specifies the rules for converting a sequence of atomic values into a string prior to attribute construction. Each node is replaced by its string value. For each adjacent sequence of one or more atomic values returned by an enclosed expression, a string 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, the function [7.1.4 The fs:item-sequence-to-string function] implements this conversion.

dynEnv |- QName => qname
dynEnv |- ExprSequence => AtomicValues

dynEnv |- attribute QName { ExprSequence } =>
       dm:attribute-node(qname,
fs:item-sequence-to-string(AtomicValues),
xs:anySimpleType)

dynEnv |- Expr => qname
dynEnv |- ExprSequence => AtomicValues

dynEnv |- attribute { Expr } { ExprSequence } =>
       dm:attribute-node(qname,
fs:item-sequence-to-string(AtomicValues),
xs:anySimpleType)

Ed. Note: DD: There are several issues with element construction:

  • Namespaces and more precise type annotations in the constructor are not supported. This is due to the bottom-up nature of element construction: in general, one does not know either the namespaces in scope or the validation-associated schema type until this element has been "seated" in some containing element (and so on recursively). See [Issue-0165:  Namespaces in element constructors].

    There is a possible solution to this chicken-and-egg problem, however: because the element constructor makes copies of its children, it could be the responsibility of the element constructor to "fill in" the values for namespaces-in-scope and schema-component on each newly-copied child (recursively), based on information provided for the node. In this scenario, these fields would remain "blank" until some appropriate activity caused a schema component to become associated with a node, etc.

    One implication of such a scheme would be that the "value" of elements could change as they are copied into a new containing element. For example, defaulted attributes could be added. Possibly the interpretation of data values would change as well, e.g. a data value supplied as a string could be re-interpreted as a number.

  • Any special treatment of xmlns, etc. that would be needed to associate namespaces with elements is not modeled.

  • Even if/when schema components are available, it is not clear when or how defaulted attributes and/or elements are created.

5.7.3 Whitespace in Constructors

Section [3.7.3 Whitespace in Constructors] in [XQuery 1.0: A Query Language for XML] describes how whitespace in element and attribute constructors is processed depending on the value of the xmlspace declaration in the query prolog. The formal semantics assumes that the rules for handling whitespace are applied prior to normalization rules, for example, during parsing of a query. Therefore, there are no formal rules for handling whitespace.

5.7.4 Other Constructors and Comments

[99 (XQuery)]   CdataSection   ::=   "<![CDATA[" Char* "]]>"
[100 (XQuery)]   XmlProcessingInstruction   ::=   "<?" PITarget Char* "?>"
[101 (XQuery)]   XmlComment   ::=   "<!--" Char* "-->"

Core Grammar

The core grammar productions for other constructors and comments are:

[75 (Core)]   XmlProcessingInstruction   ::=   "<?" PITarget Char* "?>"
[76 (Core)]   XmlComment   ::=   "<!--" Char* "-->"

Normalization

A literal XML character data (CDATA) section is normalized into a text node constructor by applying the rule for converting characters to a text node in element content.

 
[<![CDATA[" Char* "]]>]Expr
==
[Char*]ElementContent

A literal XML processing instruction is normalized into a processing instructor constructor; its character content is converted to a string as in attribute content.

 
[<? NCName Char* ?>"]Expr
==
dm:processing-instruction-node(NCName [Char*]AttributeContent)

A literal XML comment is normalized into a comment constructor; its character content is converted to a string as in attribute content.

 
[<!-- Char* -->]Expr
==
dm:comment-node([Char*]AttributeContent)

Static Type Analysis

There are no additional static type rules for CDATA, processing instructions or comments.

Dynamic Evaluation

There are no additional dynamic evaluation rules for CDATA, processing instructions or comments.

5.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 FLWRExpr in XQuery 1.0 consists of a sequence of ForClauses and LetClauses, followed by an optional WhereClause, followed by an expression to be "return"ed, 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.

[28 (XQuery)]   FLWRExpr   ::=   ((ForClause |  LetClause)+ WhereClause? OrderByClause? "return")* QuantifiedExpr
[45 (XQuery)]   ForClause   ::=   <"for" "$"> VarName TypeDeclaration? PositionalVar? "in" Expr ("," "$" VarName TypeDeclaration? PositionalVar? "in" Expr)*
[46 (XQuery)]   LetClause   ::=   <"let" "$"> VarName TypeDeclaration? ":=" Expr ("," "$" VarName TypeDeclaration? ":=" Expr)*
[86 (XQuery)]   TypeDeclaration   ::=   "as" SequenceType
[48 (XQuery)]   PositionalVar   ::=   "at" "$" VarName
[47 (XQuery)]   WhereClause   ::=   "where" Expr
[57 (XQuery)]   OrderByClause   ::=   (<"order" "by"> |  <"stable" "order" "by">) OrderSpecList
[58 (XQuery)]   OrderSpecList   ::=   OrderSpec ("," OrderSpec)*
[59 (XQuery)]   OrderSpec   ::=   Expr OrderModifier
[60 (XQuery)]   OrderModifier   ::=   ("ascending" |  "descending")? (<"empty" "greatest"> |  <"empty" "least">)? ("collation" StringLiteral)?
[25 (XPath)]   ForExpr   ::=   (SimpleForClause "return")* QuantifiedExpr
[41 (XPath)]   SimpleForClause   ::=   <"for" "$"> VarName "in" Expr ("," "$" VarName "in" Expr)*

5.8.1 FLWR expressions

Notation

Individual [For/FLWOR] clauses are normalized by means of the auxiliary normalization rules:

[FLWRClause]FLWR(Expr)

Where FLWRClause can be any either a ForClause, a LetClause, or a WhereClause:

[66 (Formal)]   FLWRClause   ::=   ForClause |  LetClause |  WhereClause

Note that, as is, this auxiliary rule normalizes a fragment of the [For/FLWOR] expression, while taking the remainder of the expression (in Expr) as an additional parameter.

Normalization

Full [For/FLWOR] expressions are normalized to nested core expressions using two sets of normalization rules. Note that some of the rules also accept ungrammatical FLWRExprs such as "where Expr1 return Expr2". This does not matter, as normalization is always applied on parsed [XPath/XQuery] expressions, and ungrammatical FLWRExprs would be rejected by the parser beforehand.

The first set of rules is applied on a full [For/FLWOR] expression, splitting it at the clause level, then applying further normalization on each separate clause.

 
[ (ForClause | LetClause | WhereClause) FLWRExpr ]Expr
==
[(ForClause | LetClause | WhereClause)]FLWR([FLWRExpr])
 
[ (ForClause | LetClause | WhereClause) return Expr ]Expr
==
[(ForClause | LetClause | WhereClause)]FLWR([Expr])

Then each [For/FLWOR] clause is normalized separately. A ForClause may bind more than one variable, whereas a for expression in the [XPath/XQuery] core binds and iterates over only one variable. Therefore, a ForClause is normalized to nested for expressions:

 
[ for Variable1 TypeDeclaration1? PositionalVar1? in Expr1,..., Variablen TypeDeclarationn? PositionalVarn? in Exprn ] FLWR(Expr)
==
for Variable1 TypeDeclaration1? PositionalVar1? in [Expr1]Expr return
  ···
     for Variablen TypeDeclarationn? PositionalVarn? in [ Exprn ]Expr return Expr

Each individual for clause, is then normalized to always have a type declaration.

Note that the additional Expr parameter of the auxiliary normalization rule is used as the final return expression.

Likewise, a LetClause clause is normalized to nested let expressions:

 
[ let Variable1 TypeDeclaration1? := Expr1, ···, Variablen TypeDeclarationn? := Exprn]FLWR(Expr)
==
let Variable1 TypeDeclaration1? := [Expr1 ]Expr return
  ···
    let Variablen TypeDeclarationn? := [Exprn]Expr return Expr

A WhereClause is normalized to an IfExpr, with the else-branch returning the empty list:

 
[ where Expr1]FLWR(Expr)
==
if ( [Expr1]Expr ) then Expr else ()

Example

The following simple example illustrates, how a FLWRExpr 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 binds 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>)

with the static type:

  element tuple {
    element i { xs:integer },
    element j { xs:integer }
  }*

5.8.2 For expression

Core Grammar

After normalization, single for expressions are described by the following core grammar production.

[23 (Core)]   ForExpr   ::=   (ForClause OrderByClause? "return")* TypeswitchExpr
[30 (Core)]   ForClause   ::=   <"for" "$"> VarName TypeDeclaration? PositionalVar? "in" Expr
[32 (Core)]   PositionalVar   ::=   "at" "$" VarName
[62 (Core)]   TypeDeclaration   ::=   "as" SequenceType

Static Type Analysis

A single for expression is typed as follows: First Type1 of the iteration expression Expr1 is inferred. Then the prime type of Type1 - prime(Type1) - is determined. This is a choice over all item types in Type1 (see also [3.5 Judgments for sequences of item types]). With the variable component of the static environment statEnv extended with Variable1 as type prime(Type1) (and Variablepos as type xs:integer, if it is present), the type Type2 of Expr2 is inferred. Because the for expression iterates over the result of Expr1, the final type of the iteration is Type2 multiplied with the possible number of items in Type1 (one, ?, *, or +). This number is determined by the auxiliary type-function quantifier(Type1).

statEnv |- Expr1 : Type1
statEnv [ varType(Variable1 : prime(Type1)) ] |- Expr2 : Type2

statEnv |- for Variable1 in Expr1 return Expr2 : Type2 · quantifier(Type1)

statEnv |- Expr1 : Type1
statEnv [ varType(Variable1 : prime(Type1), Variablepos : xs:integer) ] |- Expr2 : Type2

statEnv |- for Variable1 at Variablepos in Expr1 return Expr2 : Type2 · quantifier(Type1)

In the case a type declaration is present, the static semantics also checks that the type of the input expression is a subtype of the declared type. This semantics is specified by the following typing rule.

statEnv |- Expr1 : Type1
Type0 = [ SequenceType ]sequencetype
Type1 <: Type0
statEnv [ varType(Variable1 : prime(Type1)) ] |- Expr2 : Type2

statEnv |- for Variable1 as SequenceType in Expr1 return Expr2 : Type2 · quantifier(Type1)

statEnv |- Expr1 : Type1
Type0 = [ SequenceType ]sequencetype
Type1 <: Type0
statEnv [ varType(Variable1 : prime(Type1), Variablepos : xs:integer) ] |- Expr2 : Type2

statEnv |- for Variable1 as SequenceType at Variablepos in Expr1 return Expr2 : Type2 · quantifier(Type1)

Example

For example, if $example is bound to the sequence (<one/> , <two/> , <three/>) of type element one {}, element two {}, element three {}, then the query

  for $s in $example
  return <out> {$s} </out>

is typed as follows:

  (1) prime(element one {}, element two {}, element three {}) =
      element one {} | element two {} | element three {}
  (2) quantifier(element one {}, element two {}, element three {}) = +
  (3) $s : element one {} | element two {} | element three {}
  (4) <out> {$s} </out> : 
      element out {element one {} | element two {} | element three {}}
  (5) result-type :
      element out {element one {} | element two {} | element three {}}+

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: element out {element one {}}, element out {element two {}}, element out {element three {}}. However, inferring such a specific type for arbitrary input types and arbitrary return clauses requires significantly more complex type inference 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 Expr1 evaluates to the empty sequence, then the entire expression evaluates to the empty sequence:

dynEnv |- Expr1 => Value      empty(Value)

dynEnv |- for Variable1 TypeDeclaration? in Expr1 return Expr2 => dm:empty-sequence()

Otherwise, the iteration expression Expr1, is evaluated to produce the sequence Item1, ..., Itemn. For each item Itemi in this sequence, the body of the for expression Expr2 is evaluated in the environment dynEnv extended with Variable1 bound to Itemi. This produces values Valuei, ..., Valuen which are concatenated to produce the result sequence. If the optional positional variable Variablepos is present, it is bound to the position of the item in the input sequence, i.e., the value i.

dynEnv |- Expr1 => Item1 ,..., Itemn
dynEnv [ varValue(Variable |-> Item1) ] |- Expr2 => Value1
···
dynEnv [ varValue(Variable |-> Itemn) ] |- Expr2 => Valuen

dynEnv |- for Variable in Expr1 return Expr2 => op:concatenate(Value1 ,..., Valuen)

dynEnv |- Expr1 => Item1 ,..., Itemn
dynEnv [ varValue(Variable |-> Item1, Variablepos |-> 1) ] |- Expr2 => Value1
···
dynEnv [ varValue(Variable |-> Itemn, Variablepos |-> n) ] |- Expr2 => Valuen

dynEnv |- for Variable at Variablepos in Expr1 return Expr2 => op:concatenate(Value1 ,..., Valuen)

In the case a type declaration is present, the dynamic semantics also checks that the input value matches the declared type. This semantics is specified as the following dynamic rule.

dynEnv |- Expr1 => Item1 ,..., Itemn
Type0 = [ SequenceType ]sequencetype
Item1 matches Type0
dynEnv [ varValue(Variable |-> Item1) ] |- Expr2 => Value1
···
Itemn matches Type0
dynEnv [ varValue(Variable |-> Itemn) ] |- Expr2 => Valuen

dynEnv |- for Variable as SequenceType in Expr1 return Expr2 => op:concatenate(Value1 ,..., Valuen)

dynEnv |- Expr1 => Item1 ,..., Itemn
Type0 = [ SequenceType ]sequencetype
Item1 matches Type0
dynEnv [ varValue(Variable |-> Item1, Variablepos |-> 1) ] |- Expr2 => Value1
···
Itemn matches Type0
dynEnv [ varValue(Variable |-> Itemn, Variablepos |-> n) ] |- Expr2 => Valuen

dynEnv |- for Variable as SequenceType at Variablepos in Expr1 return Expr2 => op:concatenate(Value1 ,..., Valuen)

Ed. Note: The dynamic semantics of for could be defined without the use of ··· and using recursion. See [Issue-0134:  Should we define for with head and tail?]. The important thing is that the definition allows non-deterministic evaluation of the sequence.

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 (using the op:concatenate function):

  
  (<i>1</i>,
   <negi>-1</negi>,
   <i>2</i>,
   <negi>-2</negi>)

5.8.3 Let Expression

Core Grammar

After normalization, single let expressions are described by the following core grammar production.

[24 (Core)]   LetExpr   ::=   (LetClause "return")* TypeswitchExpr
[31 (Core)]   LetClause   ::=   <"let" "$"> VarName TypeDeclaration? ":=" Expr

Static Type Analysis

A let expression extends the type environment statEnv with Variable1 of type Type1 inferred from Expr1, and infers the type of Expr2 in the extended environment to produce the result type Type2.

statEnv |- Expr1 : Type1      statEnv [ varType(Variable1 : Type1) ] |- Expr2 : Type2

statEnv |- let Variable1 := Expr1 return Expr2 : Type2

In the case a type declaration is present, the static semantics also checks that the type of the input expression is a subtype of the declared type. This semantics is specified as the following typing rule.

statEnv |- Expr1 : Type1
Type0 = [ SequenceType ]sequencetype
Type1 <: Type0
statEnv [ varType(Variable1 : Type1) ] |- Expr2 : Type2

statEnv |- let Variable1 as SequenceType := Expr1 return Expr2 : Type2

Dynamic Evaluation

A let expression extends the dynamic environment dynEnv with Variable bound to Value1 returned by Expr1, and evaluates Expr2 in the extended environment to produce Value2.

dynEnv |- Expr1 => Value1
dynEnv [ varValue(Variable1 |-> Value1) ] |- Expr2 => Value2

dynEnv |- let Variable1 := Expr1 return Expr2 => Value2

In the case a type declaration is present, the dynamic semantics also checks that the input value matches the declared type. This semantics is specified as the following dynamic rule.

dynEnv |- Expr1 => Value1
Type0 = [ SequenceType ]sequencetype
Value1 matches Type0
dynEnv [ varValue(Variable1 |-> Value1) ] |- Expr2 => Value2

dynEnv |- let Variable1 as SequenceType := Expr1 return Expr2 => Value2

Example

Note the use of the environment discipline 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.

5.8.4 Order By

[36 (Core)]   OrderByClause   ::=   (<"order" "by"> |  <"stable" "order" "by">) OrderSpecList
[37 (Core)]   OrderSpecList   ::=   OrderSpec ("," OrderSpec)*
[38 (Core)]   OrderSpec   ::=   Expr OrderModifier
[39 (Core)]   OrderModifier   ::=   ("ascending" |  "descending")? (<"empty" "greatest"> |  <"empty" "least">)? ("collation" StringLiteral)?

Ed. Note: Issue: The semantics of order by is not currently specified. Revision is pending agreement about the semantics of sorting.See [Issue-0109:  Semantics of order by].

5.9 Unordered Expressions

Introduction

The unordered function returns its input sequence in any order.

Notation

The dynamic semantics for unordered use an auxiliary judgments which disregards order between the items in a sequence.

The following judgment

dynEnv |- Value1 permutes to Value2

holds if the sequence of items in Value2 is a permutation of the sequence of items in Value1.

Static Type Analysis

The static semantics for unordered uses the auxiliary type functions prime(Type) and quantifier(Type); which are defined in [3.5 Judgments for sequences of item types]. The type of each argument is determined, and then prime(.) and quantifier(.) are applied to the sequence type (Type1, Type2).

statEnv |- Expr1 : Type1

statEnv |- unordered(Expr1) : prime(Type1) · quantifier(Type1)

Dynamic Evaluation

The dynamic semantics for unordered is specified using the auxiliary judgments permutes to as follows.

dynEnv |- Expr1 => Value1
dynEnv |- Value1 permutes to Value2

statEnv |- unordered(Expr1) => Value2)

It is important to remark that the permutes to judgments is non deterministic. There are many sequences which can be a permutation of a given sequence. Any of those permutations would satisfy the above semantics.

5.10 Conditional Expressions

Introduction

A conditional expression supports conditional evaluation of one of two expressions.

[31 (XQuery)]   IfExpr   ::=   (<"if" "("> Expr ")" "then" Expr "else")* InstanceofExpr

Normalization

 
[if (Expr1) then Expr2 else Expr3]Expr
==
  if ([ Expr1 ]Effective_Boolean_Value) then [Expr2]Expr else [Expr3]Expr

where $fs:new is a newly created variable that does not appear in the rest of the query.

Core Grammar

The core grammar rule for the conditional expression is:

[26 (Core)]   IfExpr   ::=   (<"if" "("> Expr ")" "then" Expr "else")* CastableExpr

Static Type Analysis

statEnv |- Expr1 : xs:boolean      statEnv |- Expr2 : Type2      statEnv |- Expr3 : Type3

statEnv |- if (Expr1) then Expr2 else Expr3 : (Type2 | Type3)

Dynamic Evaluation

If the conditional's boolean expression Expr1 evaluates to true, Expr2 is evaluated and its value is produced. If the conditional's boolean expression evaluates to false, Expr3 is evaluated and its value is produced. Note that the existence of two separate evaluation rules ensures that only one branch of the conditional is evaluated.

dynEnv |- Expr1 => true      dynEnv |- Expr2 => Value2

dynEnv |- if Expr1 then Expr2 else Expr3 => Value2

dynEnv |- Expr1 => false      dynEnv |- Expr3 => Value3

dynEnv |- if Expr1 thenExpr2 elseExpr3 => Value3

5.11 Quantified Expressions

Introduction

[XPath/XQuery] defines two quantification expressions:

[29 (XQuery)]   QuantifiedExpr   ::=   ((<"some" "$"> |  <"every" "$">) VarName TypeDeclaration? "in" Expr ("," "$" VarName TypeDeclaration? "in" Expr)* "satisfies")* TypeswitchExpr
[26 (XPath)]   QuantifiedExpr   ::=   ((<"some" "$"> |  <"every" "$">) VarName "in" Expr ("," "$" VarName "in" Expr)* "satisfies")* IfExpr

Normalization

The quantification expressions are entirely normalized into other core expressions using the following normalization rules.

First, multiple variable quantifiers are normalized to single variable quantifiers.

 
[some Variable1 in Expr1, ..., Variablen in Exprn satisfies Expr]Expr
==
[
some Variable1 in Expr1 satisfies
   some Variable2 in Expr2 satistfies
         ...
     some Variablen in Exprn satistfies
     Expr
]Expr
 
[every Variable1 in Expr1, ..., Variablen in Exprn satisfies Expr]Expr
==
[
every Variable1 in Expr1 satisfies
   every Variable2 in Expr2 satistfies
         ...
     every Variablen in Exprn satistfies
     Expr
]Expr
 
[some Variable in Expr1 satisfies Expr2]Expr
==
fn:not( fn:empty(
   for Variable in [Expr1]Expr return
     if ( [ Expr2 ]Effective_Boolean_Value ) then 1
     else ()
   ))
 
[every Variable in Expr1 satisfies Expr2]Expr
==
fn:empty(
   for Variable in [Expr1]Expr return
     if ( fn:not( [ Expr2 ]Effective_Boolean_Value) ) then 1
     else ()
   )

Ed. Note: Note that the non-determinism in the semantics of quantified expressions is not modeled here. See [Issue-0136:  Non-determinism in the semantics].

Core Grammar

There are no core grammar rules for quantified expressions as they are normalized to other core expressions.

Static Type Analysis

There are no additional static type rules for the quantified expressions.

Dynamic Evaluation

There are no additional dynamic evaluation rules for the quantified expressions.

5.12 Expressions on SequenceTypes

Introduction

Expressions on SequenceTypes are expressions whose semantics depends on the type of some of the sub-expressions to which they are applied. The syntax of SequenceType expressions is described in [4.4.2 SequenceType].

5.12.1 Instance Of

[32 (XQuery)]   InstanceofExpr   ::=   CastableExpr ( <"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 "instance of" expression is normalized into a "typeswitch" 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()

5.12.2 Typeswitch

[30 (XQuery)]   TypeswitchExpr   ::=   (<"typeswitch" "("> Expr ")" CaseClause+ "default" ("$" VarName)? "return")* IfExpr
[61 (XQuery)]   CaseClause   ::=   "case" ("$" VarName "as")? SequenceType "return" Expr

Introduction

The typeswitch expression of XQuery allows users to perform different operations according to the type of an input expression.

Each branch of a typeswitch expression may have an optional "Variable" statement, used to bind a variable to the result of the input expression. This variable is optional in [XPath/XQuery] but mandatory in the [XPath/XQuery] core. One of the reasons for having this variable is that it can have a more specific type for the corresponding branch.

Normalization

Normalization of typeswitch expressions is applied to make sure an appropriate "Variable" is present in each branch.

The following general normalization rule merely adds a newly created variable which does not appear in the rest of the query. Note that $fs:new is a newly generated variable that must not conflict with any variables already in scope but is not used in any of the sub-expressions.

 
[
typeswitch ( Expr0 )
  case SequenceType1 return Expr1
    ···
  case SequenceTypen return Exprn
  default return Exprn+1
]Expr
==
typeswitch ( [ Expr0 ]Expr )
  case $fs:new1 as SequenceType1 return [ Expr1 ]Expr
    ···
  case $fs:newn as SequenceTypen return [ Exprn ]Expr
  default $fs:newn+1 return [ Exprn+1 ]Expr

Core Grammar

The core grammar productions for typeswitch are:

[25 (Core)]   TypeswitchExpr   ::=   (<"typeswitch" "("> Expr ")" CaseClause+ "default" "$" VarName "return")* IfExpr
[40 (Core)]   CaseClause   ::=   "case" "$" VarName "as" SequenceType "return" Expr

Notation

The following auxiliary grammar production is used to identify branches of the typeswitch.

[67 (Formal)]   CaseRules   ::=   ("case" SequenceType "$" VarName "return" Expr CaseRules) |  ("default" "return" "$" VarName Expr)

Notation

The following judgment

dynEnv |- Value1 against CaseRules => Value2

is used in the dynamic semantics of typeswitch. It indicate that under the environment dynEnv, and with the input value of the typeswitch being "Value1", the given case rules yields the value Value2.

Notation

The following judgment

statEnv |- Type knowing (Type1 | ... | Typen) against CaseRules : Type2

is used in the static semantics of typeswitch. It indicates that under the type environment statEnv, with the input type of the typeswitch being "Type", and with the previously visited types Type1 | ... | Typen, the given case rules (e.g., "CaseRules") has type Type2. This typing judgment keep track of all previously visited types in the typeswitch. This additional information is used later on in typing the default clause.

Static Type Analysis

The typeswitch expression possesses one of the more complex sets of static typing rules. The rules account for the fact that if the static type of the conditional expression is known, then it is possible to determine statically that some of the case clauses do not apply, and thus do not contribute to the static type of a typeswitch expression.

Like the dynamic typeswitch rule, the static typeswitch rule relies upon auxiliary rules to determine the type of each of the case clauses and of the default clause. These auxiliary rules are provided after the main rule. Note that the type of the input expression is always treated as a sequence of prime types, using the "prime" and "quantifier" operations on types. This is necessary because the further typing rules compute the common prime types for each case clause of the type switch.

Ed. Note: Jerome: the use of the common prime types replaces the previous use of type intersection. Common prime types simplifies significantly the complexity in implementing typeswitch, but is less precise in certain cases.

statEnv |- Expr0 : Type0
CaseType0 = prime(Type0) · quantifier(Type0)
CaseType1 = [ SequenceType1 ]sequencetype
    ···
CaseTypen = [ SequenceTypen ]sequencetype
statEnv |- CaseType0 knowing () against case Variable1 as SequenceType1 return Expr1 : Type1
    ···
statEnv |- CaseType0 knowing (CaseType1 | ... | CaseTypen-1) against case SequenceTypen Variablen return Exprn : Typen
statEnv |- CaseType0 knowing (CaseType1 | ... | CaseTypen) against default Variablen+1 return Exprn+1 : Typen+1

statEnv |-  
(typeswitch (Expr0)
  case Variable1 as SequenceType1 return Expr1
    ···
  case Variablen as SequenceTypen return Exprn
  default Variablen+1 return Exprn+1)
 : Type1 | ... | Typen+1

The rules that determine the static type of each case clause in the typeswitch are given next. In each rule, one needs to compute the "common prime types" between the input type and the case clause SequenceType.

The first rule is applied if the "common prime types" is none. In that case, it is known for sure the corresponding case clause is not evaluated and that the corresponding result type is none. Thanks to this rule, it is often possible to infer a precise type for the overall typeswitch by eliminating some of the cases.

CaseType = [ SequenceType ]sequencetype
common-prime(prime(CaseType0), prime(CaseType)) = none

statEnv |- CaseType0 knowing (CaseType1 | ... | CaseTyper)) against case Variable as SequenceType return Expr : none

The second rule is applied if the "common prime types" is anything other than none. In that case, the input variable is added into the type environment and type inference is applied on the expression on the right-hand side of the case clause. Note that the type of the input variable is set to the "common prime types", and not to the input type.

CaseType = [ SequenceType ]sequencetype
Type0 = common-prime(prime(CaseType0), prime(CaseType))
Occurrence0 = common-occurrence(quantifier(CaseType0), quantifier(CaseType))
not(Type0 = none)
statEnv [ varType(Variable : (Type0 · Occurrence0)) ] |- Expr : Type1

statEnv |- CaseType0 knowing (CaseType1 | ... | CaseTyper)) against case Variable as SequenceType return Expr : Type1

Note that these two rules do not take the visited datatypes into account. The "default" clause differs from the other clauses in that it does not specify a SequenceType. The typing rule for the "default" clause uses the visited type instead. Intuitively, the type corresponding to the "default" clause is any type but the ones in the other cases clauses.

Therefore, if the type of the input expression is a subtype of the choice of all visited types, then it is known for sure that the case clause is not evaluated and that the type of the default clause is none.

CaseType0 <: (CaseType1 | ... | CaseTypen)

statEnv |- CaseType0 knowing (CaseType1 | ... | CaseTyper)) against default Variable return Expr : none

Otherwise, the input variable is added into the type environment, and type inference is applied to the expression on the right-hand side of the default clause. Note that the type of the input variable is set to the input type of the expression.

not(CaseType0 <: (CaseType1 | ... | CaseTypen))
statEnv [ varType(Variable : CaseType0) ] |- Expr : Type1

statEnv |- CaseType0 knowing (CaseType1 | ... | CaseTyper)) against default Variable return Expr : Type1

Ed. Note: Jerome: There is an asymmetry here. It would be nicer to be able to have the type be more precise, like for the other case clauses. The technical problem is the need for some form of negation. I think one could define a "non-common-primes" function that would do the trick, but I leave that open for now until further review of the new typeswitch section is made. See [Issue-0112:  Typing for the typeswitch default clause].

Example

The typing rules for typeswitch provides reasonably precise type information in a number of useful cases. For example consider the following simple schema and query.

    <xs:element name="book">
       <xs:complexType>
          <xs:element name="title" type="xs:string"/>
          <xs:element name="author>
             <xs:complexType>
                <xs:element name="name" type="xs:string"/>
                <xs:element name="affiliation" type="xs:string"/>
             </xs:complexType>
          </xs:element>
       </xs:complexType>
    </xs:element>
    
    <xs:element name="bib">
       <xs:complexType>
          <xs:element ref="book" minOccurs="0" maxOccurs="unbounded"/>
       </xs:complexType>
    </xs:element>
    
    ...
    
    for $x in $bib/book/*
    return
       typeswitch $x
       case $a as element author return $a/name
       case $e as element editor return $e
       case $t as element title  return <wrote>{data($t)}</wrote>
       default return ()

The static rules for typeswitch can determine (1) that, with the given input schema, the second case matching against element editor never applies, and (2) that the data() function in the third case matching against element title, will not raise an error, because $e is guaranteed to contain data rather than more nodes. The resulting type corresponds to the following schema fragment.

    <xs:choice minOccurs="0" maxOccurs="unbounded">
       <xs:element name="name" type="xs:string"/>
       <xs:element name="wrote" type="xs:string"/>
    </xs:choice>

The type rules for typeswitch do not, however, account for the interdependence between successive case clauses. Thus if two case clauses had overlapping SequenceTypes, the static rules would behave as if both case clauses "fired", rather than just the first one.

Ed. Note: Jerome: It seems that the simpler version of typeswitch proposed here would actually allow us to take previous case clauses into account. This is something worth exploring as it would improve the static analysis in a way that might be helpful to users. See [Issue-0112:  Typing for the typeswitch default clause].

Ed. Note: Issue: There seem to be cases where the current semantics of typeswitch breaks type substitutability. See [Issue-0174:  Semantics of 'element foo of type T'].

Dynamic Evaluation

The evaluation of a typeswitch proceeds as follows. First, the input expression is evaluated, yielding an input value. Then the first case clause whose SequenceType type matches that value is selected and its corresponding expression is evaluated.

Note that the dynamic environmentdynEnv is only extended with this binding by the first auxiliary rule, which applies, if the input value matches the corresponding sequence type, or by the third auxiliary rule for the default case.

dynEnv |- Expr => Value0
dynEnv |- Value0 against CaseRules => Value1

dynEnv |- typeswitch (Expr) CaseRules => Value1

If the value matches the sequence type, the first auxiliary rule applies: It extends the environment by binding the variable Variable to Value0 and evaluates the body of the case rule.

CaseType = [ SequenceType ]sequencetype
Value0 matches CaseType
dynEnv [ varValue(Variable |-> Value0) ] |- Expr => Value1

dynEnv |- Value0 against case Variable SequenceType return Expr CaseRules => Value1

If the value does not match the sequence type, the second auxiliary rule evaluates on the remaining case rules, and the current case rule is not evaluated.

CaseType = [ SequenceType ]sequencetype      not (Value0 matches CaseType)      dynEnv |- Value0 against CaseRules => Value1

dynEnv |- Value0 against case SequenceType Variable return Expr CaseRules => Value1

Finally, the last rule states that the "default" branch of a typeswitch expression always evaluates to its given expression.

dynEnv [ varValue(Variable |-> Value0) ] Expr => Value1

dynEnv |- Value0 against default Variable return Expr => Value1

5.12.3 Cast

[50 (XQuery)]   CastExpr   ::=   <"cast" "as"> SingleType ParenthesizedExpr
[87 (XQuery)]   SingleType   ::=   AtomicType "?"?

Cast expressions change the type and value of an expression against a given type.

Core Grammar

The core grammar production for cast as is:

[34 (Core)]   CastExpr   ::=   <"cast" "as"> SingleType ParenthesizedExpr
[63 (Core)]   SingleType   ::=   AtomicType "?"?

Introduction

The expression "cast as SequenceType ( Expr )" can be used to explicitly convert the result of an expression from one type to another. It changes both the type and value of the result of an expression, and can only be applied on an atomic value.

The semantics of cast expressions follows the specification given in Section [14. Casting Functions] of the [XQuery 1.0 and XPath 2.0 Functions and Operators] document. The casting table in Section [14. Casting Functions] of the [XQuery 1.0 and XPath 2.0 Functions and Operators] document indicates whether a cast is allowed or not. In case it is allowed, a specific cast function is applied, based on the input and output XML Schema simple types. The semantics of the cast function follows casting rules which are described in the the remainder of Section [14. Casting Functions] of the [XQuery 1.0 and XPath 2.0 Functions and Operators] document and is not specified further here.

Normalization

The normalization of cast applies atomization to its argument. The type declaration asserts that the result is a single atomic value. Normalization differs whether the type is followed by ? or not.

 
[cast as AtomicType (Expr)]Expr
==
let $v as atomic value := [ Expr ]Atomize return
  cast as AtomicType ($v)
 
[cast as AtomicType? (Expr)]Expr
==
let $v as atomic value? := [ Expr ]Atomize return
  typeswitch ($v)
    case empty return ()
    default return cast as AtomicType ($v)

Notation

The following auxiliary judgments are used to represent access to the casting table and to the semantics of casting, as described in Section [14. Casting Functions] of the [XQuery 1.0 and XPath 2.0 Functions and Operators] document.

The judgment:

Type1 cast allowed Type2 => { Y, M, N }

holds if casting from type Type1 to Type2 is always possible (Y), may be possible (M), or is not allowed (N).

The notation:

cast as Type2 ( Value1 ) => Value2

indicates that applying the casting rules for Type2 on Value1 yields the value Value2.

Static Type Analysis

If the cast table indicates the cast is not allowed (N), the system raises a static type error. Otherwise, the following static typing rules give the static semantics of "cast as" expression.

statEnv |- Expr : Type1
Type2 = [ SequenceType2 ]sequencetype
Type1 cast allowed Type2 => Y or Type1 cast allowed Type2 => M

statEnv |- cast as SequenceType2 (Expr) : Type2

Dynamic Evaluation

If the cast is allowed (Y or M), the following evaluation rule applies the casting rules on the result of the input expression. The rule uses the data model function dm:type in order to obtain the dynamic type of the input value, SequenceType normalization to obtain the output type, and the above auxiliary judgments to check whether the cast is allowed and to apply the casting rules.

dynEnv |- Expr1 => Value1
Type2 = [ SequenceType2 ]sequencetype
cast as Type2 ( Value1 ) => Value2

dynEnv |- cast as SequenceType2 ( Expr1 ) => Value2

Note that in the case that the casting table indicates "M", the casting operation is allowed but might fail at run-time if the input value is inappropriate (e.g. attempting to cast the string "VRAI" into xs:boolean). In that case, the dynamic evaluation raises an error.

If the casting table returns "N", the cast is not allowed and the dynamic semantics always returns an error value.

dynEnv |- Expr1 => Value1
dm:type(Value1) = Type1
Type2 = [ SequenceType2 ]sequencetype
Type1 cast allowed Type2 => N

dynEnv |- cast as SequenceType2 ( Expr1 ) => fn:error()

5.12.4 Castable

[33 (XQuery)]   CastableExpr   ::=   ComparisonExpr ( <"castable" "as"> SingleType )

Castable expressions check whether a value can be cast to a given type.

Core Grammar

The core grammar production for cast as is:

[27 (Core)]   CastableExpr   ::=   ValueExpr ( <"castable" "as"> SingleType )

Normalization

The normalization of castable simply maps its expression argument.

 
[Expr castable as AtomicType]Expr
==
let $v as atomic value := [ Expr ]Atomize return
$v castable as AtomicType
 
[Expr castable as AtomicType]Expr
==
let $v as atomic value? := [ Expr ]Atomize return
$v castable as AtomicType?

Static Type Analysis

The static semantics of the CastableExpr requires that the type of its expression argument and the target type be atomic types.

statEnv |- Expr : Type1
Type2 = [ SequenceType2 ]sequencetype
Type1 <: fs:anyAtomicType
Type2 <: fs:anyAtomicType

statEnv |- Expr castable as SequenceType2 : xs:boolean

Ed. Note: fs:anyAtomicType is still under discussion; it denotes any singleton atomic type, i.e., any non-list type derived from xs:anySimpleType.

Dynamic Evaluation

If the casting table returns "Y" or "M" and the cast does not raise an error, then 'castable as' evaluates to true.

dynEnv |- Expr1 => Value1
Type2 = [ SequenceType2 ]sequencetype
cast as Type2 ( Value1 ) => Value2

dynEnv |- Expr1 castable as SequenceType2 => fn:true()

If the casting table returns "N", the cast is not allowed and then 'castable as' evaluates to false.

dynEnv |- Expr1 => Value1
dm:type(Value1) = Type1
Type2 = [ SequenceType2 ]sequencetype
Type1 cast allowed Type2 => N

dynEnv |- Expr1 castable as SequenceType2 => fn:false()

5.12.5 Constructor Functions

Constructor functions provide an alternative syntax for casting.

Normalization

Constructor functions are normalized to explicit cast as operations.

 
[AtomicType(Expr)]Expr
==
[cast as AtomicType (Expr)]Expr

5.12.6 Treat as

[51 (XQuery)]   TreatExpr   ::=   <"treat" "as"> SequenceType ParenthesizedExpr

Introduction

The expression "treat as SequenceType ( Expr )", can be used to change the static type of the result of an expression without changing its value. Treat as raises a static type error, if the static type of expression and the specified type are incompatible. Treat as raises a run-time error, if the dynamic type of the expression is not an instance of 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 which must not conflict with any variables already in scope.

 
[treat as SequenceType ( Expr )]Expr
==
typeswitch ([ Expr ]Expr) as $fs:new
  case SequenceType return $fs:new
  default return fn:error()

5.13 Validate Expressions

[49 (XQuery)]   ValidateExpr   ::=   (<"validate" "{"> |  (<"validate" "context"> SchemaGlobalContext ("/" SchemaContextStep)* "{")) Expr "}"

Core Grammar

The core grammar production for validate is:

[33 (Core)]   ValidateExpr   ::=   (<"validate" "{"> |  (<"validate" "context"> SchemaGlobalContext ("/" SchemaContextStep)* "{")) Expr "}"

A validate expression validates its argument with respect to the in-scope schema definitions, using the schema validation process described in [XML Schema]. The argument to a validate expression may be any sequence of elements. Validation replaces element and attribute nodes with new nodes that have their own identity and contain type annotations and defaults created by the validation process. If a node that has a parent is validated, the parent of the original node will not be the parent of the validated node.

Static Type Analysis

Ed. Note: Issue: The current form of validate cannot be typed statically. See [Issue-0166:  Static typing for validate].

Dynamic Evaluation

An important effect of validation is that it removes existing type annotations and values (erasure), and it revalidates the corresponding data model instance, possibly adding new type annotations and values (annotation). Both erasure and annotation are described formally in [3.8 Judgments for the validate expression]. Indeed, the conjunction of erasure and annotation provides a formal model for a large part of actual schema validation. The semantics of the "validate" operation is (partially) specified as follows.

dynEnv.varValue |- Expr => Value1
Value1 erases to element ElementName { Value2 }
annotate as element ElementName (element ElementName { Value2 }) => Value3

dynEnv |- validate element ElementName { Expr } => Value3

Ed. Note: Issue: This semantics only applies when validating against a top-level element. See [Issue-0138:  Semantics of Schema Context]

6 The Query Prolog

Introduction

The Query Prolog is a series of declarations and definitions that affect query processing. The Query Prolog can be used to define namespaces, import type definitions from XML Schemas, and define functions. Namespace declarations and schema imports always precede function definitions, as specified by the following grammar productions.

[21 (XQuery)]   Query   ::=   QueryProlog QueryBody
[22 (XQuery)]   QueryProlog   ::=   (NamespaceDecl
|  XMLSpaceDecl
|  DefaultNamespaceDecl
|  DefaultCollationDecl
|  SchemaImport)* FunctionDefn*
[23 (XQuery)]   QueryBody   ::=   ExprSequence?

The order in which functions are defined is immaterial. Notably, user-defined functions may invoke other user-defined functions in any order.

Namespace Declarations and Schema Import are not part of the query proper but are used to modify the input context for the rest of the query processing. Namespace Declarations and Schema Import are processed before the normalization phase.

The semantics of Schema Import is described in terms of the XQuery type system. The process of converting an XML Schema into a sequence of type declarations is described in Section [8 Importing Schemas]. This section describes how the resulting sequence of type declarations is added into the static environment when the prolog is processed.

Notation

Prolog declarations are either namespace declarations or type declarations.

[68 (Formal)]   PrologDeclList   ::=   PrologDecl*
[69 (Formal)]   PrologDecl   ::=   NamespaceDecl
|  XMLSpaceDecl
|  DefaultNamespaceDecl
|  DefaultCollationDecl
|  SchemaImport

Notation

The following auxiliary judgments are used when processing the [XPath/XQuery] prolog.

The judgment:

PrologDeclList => statEnv

holds if the sequence of prolog declarations PrologDeclList yields the static environment statEnv.

The judgment:

statEnv1 |- PrologDecl => statEnv2

holds if under the static environment statEnv1, the single prolog declarations PrologDeclList yields the new static environment statEnv2.

Context Processing

Prolog declarations are processed in the order they are encountered, as described by the following inference rules. The first rule specifies that for an empty sequence of prolog declarations, the static environment is composed of a default context.

Ed. Note: Jerome: What do the default namespace and type environments contain? I believe at least the default namespace environment should contain the "xs", "fn" and "op" prefixes, as well as the default namespaces bound to the empty namespace. Should the default type environment contain wildcard types? See [Issue-0115:  What is in the default context?].


() => statEnvDefault

PrologDeclList => statEnv1
statEnv1 |- PrologDecl => statEnv2

PrologDecl PrologDeclList => statEnv2

6.1 Namespace Declarations

[109 (XQuery)]   NamespaceDecl   ::=   <"declare" "namespace"> NCNameForPrefix "=" URLLiteral
[111 (XQuery)]   DefaultNamespaceDecl   ::=   (<"default" "element"> |  <"default" "function">) "namespace" "=" URLLiteral

Context Processing

A namespace declaration adds a new (prefix,uri) binding in the namespace component of the static environment.

statEnv1 = statEnv [ namespace(NCName |-> StringLiteral) ]

statEnv |- namespace NCName = StringLiteral => statEnv1

A default element namespace declaration changes the default element namespace prefix binding in the namespace component of the static environment.

statEnv1 = statEnv [ namespace(fsdefaultelem |-> StringLiteral) ]

statEnv |- default element namespace = StringLiteral => statEnv1

A default function namespace declaration changes the default function namespace prefix binding in the namespace component of the static environment.

statEnv1 = statEnv [ namespace(fsdefaultfunc |-> StringLiteral) ]

statEnv |- default function namespace = StringLiteral => statEnv1

Note that for namespaces, later declarations can override earlier declarations of the same prefix.

6.2 Schema Imports

[114 (XQuery)]   SchemaImport   ::=   <"import" "schema"> (StringLiteral |  SubNamespaceDecl |  DefaultNamespaceDecl) <"at" StringLiteral>?
[110 (XQuery)]   SubNamespaceDecl   ::=   "namespace" NCNameForPrefix "=" URLLiteral

Notation

The following auxiliary judgments are used when processing schema imports.

The judgment:

statEnv1 |- Definition* => statEnv2

holds if under the static environment statEnv1, the sequence of type definitions Definition* yields the new static environment statEnv2.

The judgment:

statEnv1 |- Definition => statEnv2

holds if under the static environment statEnv1, the single definition Definition yields the new static environment statEnv2.

Context Processing

Schema imports are first imported into the query type system and yield a sequence of type definitions. Then each type definitions is added to the static environment.

Definition* = [Schema]Schema
statEnv |- Definition* => statEnv1

statEnv |- import schema Schema => statEnv1

An empty sequence of definitions yields the original environment.


statEnv |- () => statEnv

Each definition is added into the static environment.

statEnv |- Definition* => statEnv1
statEnv1 |- Definition1 => statEnv2

Definition1 Definition* => statEnv2

Type, element and attribute declarations are added respectively to the type, element and attribute declarations components of the static environment.

statEnv1 = statEnv [ typeDefn(TypeName |-> define type TypeName TypeDerivation ) ]

statEnv |- define type TypeName TypeDerivation => statEnv1

statEnv1 = statEnv [ elemDecl(ElementName |-> define element ElementName Substitution? Nillable? TypeReference) ]

statEnv |- define element ElementName Substitution? Nillable? TypeReference => statEnv1

statEnv1 = statEnv [ attrDecl(AttributeName |-> define attribute AttributeName TypeReference) ]

statEnv |- define attribute AttributeName TypeReference => statEnv1

Note that for namespaces, later declarations can override earlier declarations of the same prefix. In the case of global elements, attributes and types, multiple declarations correspond to an error.

6.3 Xmlspace Declaration

[107 (XQuery)]   XMLSpaceDecl   ::=   <"declare" "xmlspace"> "=" ("preserve" |  "strip")

The impact of xmlspace declaration is not formally specified in this document.

6.4 Default Collation

[108 (XQuery)]   DefaultCollationDecl   ::=   <"default" "collation" "="> URLLiteral

The impact of default collation is not formally specified in this document. See [Issue-0160:  Collations in the static environment].

6.5 Function Definitions

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.

[112 (XQuery)]   FunctionDefn   ::=   <"define" "function"> <QName "("> ParamList? (")" |  (<")" "as"> SequenceType)) EnclosedExpr
[113 (XQuery)]   ParamList   ::=   Param ("," Param)*
[82 (XQuery)]   Param   ::=   "$" VarName TypeDeclaration?

Notation

The following auxiliary mapping rule is used for the normalization of parameters in function definitions: []Param.

Normalization

The only form of normalization required for user defined functions is adding the type for its parameters or for the return clause if it is not provided.

 
[ define function QName ( ParamList? ) as SequenceType EnclosedExpr ]Expr
==
define function [QName] ( [ParamList?]Param ) as SequenceType [EnclosedExpr]Expr

If the return type of the function is not provided, it is given the item* sequence type.

 
[define function QName ( ParamList? ) EnclosedExpr ]Expr
==
define function [QName] ( [ParamList?]Param ) as item* [EnclosedExpr]Expr

Parameters without a declared typed are given the item* sequence type.

 
[Variable]Param
==
item* Variable
 
[SequenceType Variable]Param
==
SequenceType Variable

Context Processing

First, all the function signatures are added into the static environment, and all the function bodies are added into the dynamic environment. This process happens before static type analysis occurs.

FunctionDefnList => statEnv, dynEnv
statEnv' = statEnv [ funcType(QName |-> ( SequenceType1 , ··· SequenceTypen , SequenceTyper)) ]
dynEnv' = dynEnv [ funcDefn(QName |-> ( Expr , Variable1 , ··· Variablen)) ]

FunctionDefnList define function QName ( SequenceType1 Variable1, ··· SequenceTypen Variablen )
as SequenceTyper
{ Expr } => statEnv', dynEnv'

Static Type Analysis

The static typing rules for function definitions checks whether the type of the enclosed expression is consistent with the type of the input parameters, and the type of the return clause.

statEnv [ varType( Variable1 : SequenceType1 ;...; Variablen : SequenceTypen ) ] |- Expr : Type
Type <: SequenceTyper

statEnv |- define function QName ( SequenceType1 Variable1 , ··· SequenceTypen Variablen )
as SequenceTyper
{ Expr }

What this typing rule is checking is: if the input parameters are of the given type, then is it true that the result of the function is of the return type. If the type checking fails, the system raises an error. Otherwise, it does not have any other effect, as function signatures are already inside the static environment.

Dynamic Evaluation

There is no need to describe a dynamic semantics at this point, as functions are only evaluated when called. The actual semantics of function calls is described in [5.1.4 Function Calls].

7 Additional Semantics of Functions

Ed. Note: Status: This section is still incomplete. This section will be completed as soon as Sections 4 and 5 are consolidated. See [Issue-0135:  Semantics of special functions].

As was explained in section [2.5 Functions], a number of functions play a role in defining the formal semantics of [XPath/XQuery]. Some other functions from the [XQuery 1.0 and XPath 2.0 Functions and Operators] document need special static typing rules. This section gives the semantics of all "special" functions, used in the formal semantics.

7.1 Formal Semantics Functions

Introduction

This section gives the definition and semantics of functions which are used in the formal semantics but are not part of the [XQuery 1.0 and XPath 2.0 Functions and Operators] document.

7.1.1 The fs:characters-to-string function

The fs:characters-to-string function takes a sequence of character values and synthecizes a string.

7.1.2 The fs:distinct-doc-order function

The fs:distinct-doc-order function sorts by document order and removes duplicates. It is defined as the composition of the [XQuery 1.0 and XPath 2.0 Functions and Operators] functions fn:distinct-nodes and sorting by document order.

The dynamic semantics of fs:distinct-doc-order cannot be specified as a simple order by expression. See [Issue-0168:  Sorting by document order].

7.1.3 The fs:item-sequence-to-node-sequence function

The fs:item-sequence-to-node-sequence function converts a sequence of item values to nodes by applying the rules in Section [3.7.2 Data Model Representation] in .

7.1.4 The fs:item-sequence-to-string function

The fs:item-sequence-to-node-sequence function converts a sequence of item values to a string by applying the rules in Section [3.7.2 Data Model Representation] in .

In particular, each node is replaced by its string value. For each adjacent sequence of one or more atomic values returned by an enclosed expression, a string is constructed, containing the canonical lexical representation of all the atomic values, with a single blank character inserted between adjacent values.

7.2 Functions with specific typing rules

7.2.1 The fn:error function

Static Type Analysis

The fn:error function always returns the none type.


statEnv |- fn:error() : none

7.2.2 The fn:distinct-nodes, and fn:distinct-values functions

Static Type Analysis

The fn:distinct-nodes function takes a sequence of nodes as input and returns a sequence of prime types.

statEnv |- Expr : Type
statEnv |- Type <: node*

statEnv |- fn:distinct-nodes(Expr) : prime(Type) · quantifier(Type)

The fn:distinct-values function takes a sequence of atomic values as input and returns a sequence of prime types.

statEnv |- Expr : Type
statEnv |- Type <: atomic value*

statEnv |- fn:distinct-values(Expr) : prime(Type) · quantifier(Type)

7.2.3 The op:union, op:intersect and op:except operators

Static Type Analysis

The static semantics for op:union uses the auxiliary type functions prime(Type) and quantifier(Type); which are defined in [3.5 Judgments for sequences of item types]. The type of each argument is determined, and then prime(.) and quantifier(.) are applied to the sequence type (Type1, Type2).

statEnv |- Expr1 : Type1      statEnv |- Expr2 : Type2

statEnv |- op:union(Expr1, Expr2) : prime(Type1 , Type2) · quantifier(Type1 , Type2)

The static semantics of op:intersect is analogous to that for op:union, but uses the common-prime and common-occurrence operations. Because an intersection may always be empty, the result type needs to be made optional.

statEnv |- Expr1 : Type1
statEnv |- Expr2 : Type2
statEnv |- PrimeType3 = common-prime(prime(Type1), prime(Type2))
statEnv |- Occurrence3 = common-occurrence(quantifier(Type1), quantifier(Type2))

statEnv |- op:intersect(Expr1, Expr2) : PrimeType3 · Occurrence3 ?

The static semantics of op:except follows. The type of the second argument is ignored as it does not contribute to the result type. Like with op:intersect the result of op:except may be the empty list.

statEnv |- Expr1 : Type1

statEnv |- op:except(Expr1, Expr2) : prime(Type1) · quantifier(Type1) · ?

7.2.4 The op:to operator

The static semantics of the op:to function states that it always returns an integer sequence:

statEnv |- Expr1 : xs:integer      statEnv |- Expr2 : xs:integer

statEnv |- op:to(Expr1, Expr2) : xs:integer*

Ed. Note: MFF: the binary operator "to" is not defined on empty sequences. The [XQuery 1.0 and XPath 2.0 Functions and Operators] document says operands are decimals, while the XQuery document says they are integers. What happens when Expr1 > Expr2? See [Issue-0119:  Semantics of op:to].

7.2.5 The fn:data function

Introduction

The fn:data function is used to access the value content of an element or attribute. This function corresponds to the dm:typed-value accessor in the [XPath/XQuery] data model.

Ed. Note: Some aspects of the semantics of the fn:data() function are still an open issue. For instance, what should be the result of fn:data() over a text node. See [Issue-0107:  Semantics of data()].

Notation

Infering the type for the fn:data function is done by applying the fn:data function as a Filter, using the same approach as for the XPath steps.

The following notation, adapted from the Filter judgment in [5.2.1 Steps], is used.

dynEnv.varValue ; Type1 |- fn:data : Type2

Static Type Analysis

Static type analysis for the fn:data function checks that the function is applied on an element or attribute with a simple type content. If so, it returns the corresponding simple type through an application of the Filter judgment on the input type of the function.

statEnv |- Expr : Type1
statEnv |- Type1 <: (element { attribute*, xs:anySimpleType } | attribute })
dynEnv.varValue ; Type1 |- fn:data : Type2

statEnv |- fn:data(Expr) : Type2


statEnv ; element ElementName { AttrType, SimpleType } |- fn:data : SimpleType;


statEnv ; attribute AttributeName { SimpleType } |- fn:data : SimpleType;

If applied on any other kind of item, it returns the empty sequence.

statEnv |- Expr : Type
statEnv |- not(Type <: (element { attribute*, xs:anySimpleType } | attribute))
statEnv |- Type <: item

dynEnv |- fn:data(Expr) : ()

Otherwise (for empty sequences or sequences of more than one item value), it raises an error.

Example

Consider the following variables 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)

Remark that, as the input type is a choice, applying the Filter judgment results in a choice of simple types for the output of the fn:data function.

Dynamic Evaluation

Dynamically, the fn:data function is implemented as the dm:typed-value data model accessor.

dynEnv |- Expr => Value1      dm:typed-value(Value1) = Value2

dynEnv |- fn:data(Expr) => Value2

8 Importing Schemas

Ed. Note: Status:This section has been extensively revised to reflect the addition of named typing to the [XPath/XQuery] type system, and improve the editorial level. Feedback on the new mapping and on the new presentation is solicited.

This section describes how XML Schema declarations, as specified by [XML Schema] are imported into the [XPath/XQuery] type system.

8.1 Introduction

At compile time, 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.

8.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 which are relevant for [XPath/XQuery], are modeled within the [XPath/XQuery] type system, and handled by the mapping.

  • Not yet indicates features which are relevant for [XPath/XQuery], but are not yet modeled within the [XPath/XQuery] type system or are not yet handled by the mapping. Those features correspond to open issues. 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 which are relevant for [XPath/XQuery], but are not modeled within the [XPath/XQuery] type system, and are not handled by the mapping. Such feature are typically only related to validation, for which the formal semantics will only give a partial model.

  • Ignored Indicates features which are not relevant for [XPath/XQuery], are not modeled within 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 typesHandled
Simple type derivation by restrictionHandled
Derivation by list and unionHandled
Facets on simple typesNot handled
ID and IDREF constraintsIgnored
Attribute Declarations
    default,fixed,useNot yet
Element Declarations
    default, fixed (value constraint)Not yet
    nillableHandled
    substitution group affiliationHandled
    substitution group exclusionsIgnored
    disallowed substitutionsIgnored
    abstractNot yet
Complex Type Definitions
    derivation by restrictionHandled
    derivation by extensionHandled
    finalIgnored
    abstractNot yet
AttributeUses
    requiredNot yet, mapping only
    default, fixed (value constraint)Not yet
Attribute Group DefinitionsNot yet, mapping only
Model Group DefinitionsNot yet, mapping only
Model GroupsHandled
ParticlesHandled
Wildcards
    process contents strict, skip, laxNot yet
Identity-constraint DefinitionsIgnored
Notation DeclarationsIgnored
AnnotationsIgnored

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.

8.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 attributes with non-schema namespace . . .} >
        Content: (annotation?, (simpleContent | complexContent | ((group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?))))
  </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.

[53 (Formal)]   ComplexTypeContent   ::=   "annotation"? ("simpleContent" |  "complexContent" |  (ChildrenContent AttributeContent))
[56 (Formal)]   AttributeContent   ::=   ("attribute" |  "attributeGroup")* "anyAttribute"?
[54 (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>

8.1.3 Main mapping rules

Notation

The normalization rule

 
[Schema]Schema
==
Definition*

maps a complete schema into a set of Definition in the [XPath/XQuery] type system.

The normalization rule

 
[SchemaComponent]definition(targetNCName)
==
Definition

maps a toplevel schema component into a Definition in the [XPath/XQuery] type system, given the target namespace .

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 .

8.1.4 Special attributes

The XML Schema attributes: use, minOccurs, maxOccurs, mixed, nillable, and substitutionGroup, require specific mapping rules.

8.1.4.1 use

The "use" attribute is used to describe the occurrence and default behavior of a given attribute.

Notation

The following auxiliary grammar productions are used to describe the "use" attribute.

The normalization rule

 
[UseAttribute]use
==
Occurrence

maps the use attribute UseAttribute in Schema into the occurrence indicator Occurrence in the [XPath/XQuery] type system.

Schema mapping

Use attributes are mapped to the type system in the following way.

 
use = "optional"use
==
?
 
use = "required"use
==

Ed. 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.

8.1.4.2 minOccurs and maxOccurs

Notation

The following auxiliary grammar productions are used to describe occurrence attributes.

[52 (Formal)]   OccursAttributes   ::=   "maxOccurs" "minOccurs"
[50 (Formal)]   maxOccurs   ::=   "maxOccurs" "=" ("nonNegativeInteger" |  "unbounded")
[51 (Formal)]   minOccurs   ::=   "minOccurs" "=" "nonNegativeInteger"

The normalization rule

 
[OccursAttributes]occurs
==
Occurrence

maps the occurrence attributes OccursAttributes in Schema into the occurrence indicator Occurrence 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 n >= m > 1

8.1.4.3 mixed

Notation

The following auxiliary grammar productions are used to describe the "mixed" attribute.

[47 (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
==
8.1.4.4 nillable

Notation

The following auxiliary grammar productions are used to describe the "nillable" attribute.

[48 (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
==
8.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.

[49 (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.

8.1.5 Anonymous type names

Notation

As explained in [3 The 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.

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

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

8.2.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 [Anonk] be a newly generated anonymous name.

 
[
  <attribute
        name = NCName
       UseAttribute>
        simpleType
  </attribute>
]content(targetNCName)
==
( attribute targetNCName:NCName of type [Anonk] )[UseAttribute]use
  with
define type [Anonk] of type xs:anySimpleType { [simpleType]content(targetNCName) }

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

8.3.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>
        ElementContent
  </element>
]definition(targetNCName)
==
define element targetNCName:NCName [substitutionGroupAttribute]substitution [NillableAttribute]nillable [ElementContent]content(targetNCName)

8.3.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 [Anonk] be a newly generated anonymous name.

 
[
  <element
       OccursAttributes
        name = NCName
       NillableAttribute>
        ElementContent
  </element>
]definition(targetNCName)
==
( element targetNCName:NCName [NillableAttribute]nillable of type [Anonk] ) [OccursAttributes]occurs
  with
define type [Anonk] [ElementContent]content(targetNCName) }

8.4 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.

[53 (Formal)]   ComplexTypeContent   ::=   "annotation"? ("simpleContent" |  "complexContent" |  (ChildrenContent AttributeContent))
[56 (Formal)]   AttributeContent   ::=   ("attribute" |  "attributeGroup")* "anyAttribute"?
[54 (Formal)]   ChildrenContent   ::=   ("group" |  "all" |  "choice" |  "sequence")?

8.4.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.

8.4.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.

8.4.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)
==
TypeSpecifier

maps a pair of mixed attribute and complex type content to a type specifier.

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

8.4.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) }

8.5 Attribute Uses

Mapping for attribute uses is given in [8.1.4.1 use].

8.6 Attribute Group Definitions

8.6.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-0158:  Support for XML Schema groups].

8.6.2 Attribute group reference

Schema mapping

Attribute group references are not currently handled by the mapping. See [Issue-0158:  Support for XML Schema groups].

8.7 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-0158:  Support for XML Schema groups].

8.8 Model Groups

Model groups are either "all", "sequence" or "choice". One can also refer to a model group definition.

8.8.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>
        Element1 ... Elementn
  </all>
]content(targetNCName)
==
([Element1]content(targetNCName) & ... & [Elementn]content(targetNCName)) [OccursAttributes]occurs

8.8.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.

[55 (Formal)]   GroupComponent   ::=   "element" |  "group" |  "choice" |  "sequence" |  "any"

Schema mapping

Choice groups are mapped into the "|" operation in the [XPath/XQuery] type system.

.
 
[
  <choice
       OccursAttributes>
        GroupComponent1 ... GroupComponentn
  </choice>
]content(targetNCName)
==
([GroupComponent1]content(targetNCName) | ... | [GroupComponentn]content(targetNCName)) [OccursAttributes]occurs

8.8.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

Choice groups are mapped into the "," operation in the [XPath/XQuery] type system.

.
 
[
  <sequence
       OccursAttributes>
        GroupComponent1 ... GroupComponentn
  </sequence>
]content(targetNCName)
==
([GroupComponent1]content(targetNCName) , ... , [GroupComponentn]content(targetNCName)) [OccursAttributes]occurs

8.9 Particles

Particles contribute to the definition of content models.

Particle can be either and element reference, a group reference or a wildcard.

8.9.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

8.9.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.

8.10 Wildcards

8.10.1 Attribute wildcards

Schema component

Attribute wilcards 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*

Ed. Note: Issue: Attribute wildcards with a "lax" or "strict" process content are not currently handled by the mapping. See [Issue-0153:  Support for lax and strict wildcards].

Ed. Note: Issue: Namespace wildcards are not currently handled by the mapping. See [Issue-0157:  Support for wildcard namespaces].

8.10.2 Element wildcards

Schema component

Element wilcards 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 )[OccursAttributes]occurs

Ed. Note: Issue: Element wildcards with a "lax" or "strict" process content are not currently handled by the mapping.

Ed. Note: Issue: Namespace wildcards are not currently handled by the mapping. See [Issue-0157:  Support for wildcard namespaces].

8.11 Identity-constraint Definitions

All identity-constraints definitions are ignored when mapping into the [XPath/XQuery] type system.

8.12 Notation Declarations

All notation declarations are ignored when mapping into the [XPath/XQuery] type system.

8.13 Annotation

All annotation are ignored when mapping into the [XPath/XQuery] type system.

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

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

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

8.14.3 Simple type content

Notation

The normalization rule []simple_content(targetNCName) maps a simple type content to a type specifier.

Schema mapping

If the simple type 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.)

 
[
  <restriction
        base = QName>
        simpleContentRestriction
  </restriction>
]simple_content(targetNCName)
==
restricts QName { QName }

If the simple type is derived by list, it is mapped into a repetition type into the [XPath/XQuery] type system.

 
[
  <list>
SimpleType
  </list>
]simple_content(targetNCName)
==
{ ([SimpleType]content(targetNCName))* }
 
[
  <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>
SimpleType1 ... SimpleTypen
  </union>
]simple_content(targetNCName)
==
{ ([SimpleType]content(targetNCName) | ... | [SimpleTypen]content(targetNCName)) }
 
[
  <union
        memberTypes = QName1 ... QNamen />
]simple_content(targetNCName)
==
{ QName1 | ... | QNamen }

8.15 Schemas as a whole

8.15.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.

[45 (Formal)]   Pragma   ::=   ("include" |  "import" |  "redefine" |  "annotation")*
[46 (Formal)]   Content   ::=   (("simpleType" |  "complexType" |  "element" |  "attribute" |  "attributeGroup" |  "group" |  "notation") "annotation"*)*

The auxiliary normalization rule

 
[Pragma]pragma(targetNCName)
==
Definition*

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.

 
[schema URI]Expr
==
[open-schema-document(URI)]Schema
 
[
  <schema
        targetNamespace = targetURI>
        Pragma Content
  </schema>
]Schema
==
[Pragma]pragma(targetNCName) [Content]definition(targetNCName)

8.15.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.

8.15.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.

8.15.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.

A Normalized core grammar

This section contains the grammar of [XPath/XQuery] after it has been normalized, sometimes referred to as the "core" syntax.

A.1 Core lexical structure

A.1.1 Syntactic Constructs

A.2 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.

NON-TERMINALS

[1]   Query   ::=   QueryProlog QueryBody
[2]   QueryProlog   ::=   (NamespaceDecl
|  XMLSpaceDecl
|  DefaultNamespaceDecl
|  DefaultCollationDecl
|  SchemaImport)* FunctionDefn*
[3]   QueryBody   ::=   ExprSequence?
[4]   ExprSequence   ::=   Expr ("," Expr)*
[5]   Expr   ::=   ForExpr
|  ForExpr
[6]   ForExpr   ::=   (ForClause OrderByClause? "return")* TypeswitchExpr
[7]   LetExpr   ::=   (LetClause "return")* TypeswitchExpr
[8]   TypeswitchExpr   ::=   (<"typeswitch" "("> Expr ")" CaseClause+ "default" "$" VarName "return")* IfExpr
[9]   IfExpr   ::=   (<"if" "("> Expr ")" "then" Expr "else")* CastableExpr
[10]   CastableExpr   ::=   ValueExpr ( <"castable" "as"> SingleType )
[11]   ValueExpr   ::=   ValidateExpr |  CastExpr |  Constructor |  StepExpr
[12]   StepExpr   ::=   ForwardStep |  ReverseStep |  PrimaryExpr
[13]   ForClause   ::=   <"for" "$"> VarName TypeDeclaration? PositionalVar? "in" Expr
[14]   LetClause   ::=   <"let" "$"> VarName TypeDeclaration? ":=" Expr
[15]   PositionalVar   ::=   "at" "$" VarName
[16]   ValidateExpr   ::=   (<"validate" "{"> |  (<"validate" "context"> SchemaGlobalContext ("/" SchemaContextStep)* "{")) Expr "}"
[17]   CastExpr   ::=   <"cast" "as"> SingleType ParenthesizedExpr
[18]   Constructor   ::=   XmlComment
|  XmlProcessingInstruction
|  ComputedDocumentConstructor
|  ComputedElementConstructor
|  ComputedAttributeConstructor
|  ComputedTextConstructor
[19]   OrderByClause   ::=   (<"order" "by"> |  <"stable" "order" "by">) OrderSpecList
[20]   OrderSpecList   ::=   OrderSpec ("," OrderSpec)*
[21]   OrderSpec   ::=   Expr OrderModifier
[22]   OrderModifier   ::=   ("ascending" |  "descending")? (<"empty" "greatest"> |  <"empty" "least">)? ("collation" StringLiteral)?
[23]   CaseClause   ::=   "case" "$" VarName "as" SequenceType "return" Expr
[24]   PrimaryExpr   ::=   Literal |  FunctionCall |  ("$" VarName) |  ParenthesizedExpr
[25]   ForwardAxis   ::=   <"child" "::">
|  <"descendant" "::">
|  <"attribute" "::">
|  <"self" "::">
|  <"descendant-or-self" "::">
|  <"following-sibling" "::">
|  <"following" "::">
|  <"namespace" "::">
[26]   ReverseAxis   ::=   <"parent" "::">
|  <"ancestor" "::">
|  <"preceding-sibling" "::">
|  <"preceding" "::">
|  <"ancestor-or-self" "::">
[27]   NodeTest   ::=   KindTest |  NameTest
[28]   NameTest   ::=   QName |  Wildcard
[29]   Wildcard   ::=   "*" |  <NCName ":" "*"> |  <"*" ":" NCName>
[30]   KindTest   ::=   ProcessingInstructionTest
|  CommentTest
|  TextTest
|  AnyKindTest
[31]   ProcessingInstructionTest   ::=   <"processing-instruction" "("> StringLiteral? ")"
[32]   CommentTest   ::=   <"comment" "("> ")"
[33]   TextTest   ::=   <"text" "("> ")"
[34]   AnyKindTest   ::=   <"node" "("> ")"
[35]   ForwardStep   ::=   ForwardAxis NodeTest
[36]   ReverseStep   ::=   ReverseAxis NodeTest
[37]   NumericLiteral   ::=   IntegerLiteral |  DecimalLiteral |  DoubleLiteral
[38]   Literal   ::=   NumericLiteral |  StringLiteral
[39]   ParenthesizedExpr   ::=   "(" ExprSequence? ")"
[40]   FunctionCall   ::=   <QName "("> (Expr ("," Expr)*)? ")"
[41]   Param   ::=   "$" VarName TypeDeclaration
[42]   SchemaContext   ::=   "context" SchemaGlobalContext ("/" SchemaContextStep)*
[43]   SchemaGlobalContext   ::=   QName |  <"type" QName>
[44]   SchemaContextStep   ::=   QName
[45]   TypeDeclaration   ::=   "as" SequenceType
[46]   SingleType   ::=   AtomicType "?"?
[47]   SequenceType   ::=   (ItemType OccurrenceIndicator) |  "empty"
[48]   ItemType   ::=   (("element" |  "attribute") ElemOrAttrType?)
|  "node"
|  "processing-instruction"
|  "comment"
|  "text"
|  "document"
|  "item"
|  AtomicType
|  "untyped"
|  <"atomic" "value">
[49]   ElemOrAttrType   ::=   (QName (SchemaType |  SchemaContext?)) |  SchemaType
[50]   SchemaType   ::=   <"of" "type"> QName
[51]   AtomicType   ::=   QName
[52]   OccurrenceIndicator   ::=   ( |  "*" |  "+" |  "?")?
[53]   ComputedDocumentConstructor   ::=   <"document" "{"> ExprSequence "}"
[54]   ComputedElementConstructor   ::=   (<"element" QName "{"> |  (<"element" "{"> Expr "}" "{")) ExprSequence? "}"
[55]   ComputedAttributeConstructor   ::=   (<"attribute" QName "{"> |  (<"attribute" "{"> Expr "}" "{")) ExprSequence? "}"
[56]   ComputedTextConstructor   ::=   <"text" "{"> ExprSequence? "}"
[57]   CdataSection   ::=   "<![CDATA[" Char* "]]>"
[58]   XmlProcessingInstruction   ::=   "<?" PITarget Char* "?>"
[59]   XmlComment   ::=   "<!--" Char* "-->"
[60]   EnclosedExpr   ::=   ( |  "{") ExprSequence "}"
[61]   XMLSpaceDecl   ::=   <"declare" "xmlspace"> "=" ("preserve" |  "strip")
[62]   DefaultCollationDecl   ::=   <"default" "collation" "="> URLLiteral
[63]   NamespaceDecl   ::=   <"declare" "namespace"> NCNameForPrefix "=" URLLiteral
[64]   SubNamespaceDecl   ::=   "namespace" NCNameForPrefix "=" URLLiteral
[65]   DefaultNamespaceDecl   ::=   (<"default" "element"> |  <"default" "function">) "namespace" "=" URLLiteral
[66]   FunctionDefn   ::=   <"define" "function"> <QName "("> ParamList? (")" |  (<")" "as"> SequenceType)) EnclosedExpr
[67]   ParamList   ::=   Param ("," Param)*
[68]   SchemaImport   ::=   <"import" "schema"> (StringLiteral |  SubNamespaceDecl |  DefaultNamespaceDecl) <"at" StringLiteral>?

B Mapping of Overloaded Internal Functions

The table in this section maps the overloaded internal functions (with prefix fs:) to the monomorphic operator functions defined in (with prefix fn:). These functions are included in the initial function declaration environment statEnv.funcType.

Note that in the following table, all numeric functions are applied to operands with the same type. Values are promoted to compatible types in the function call semantics.

In the following tables, the term 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.)

Internal FunctionType(A)Type(B)FunctionResult type
fs:plus(A, B)xs:integerxs:integerop:numeric-add(A, B)xs:integer
fs:plus(A, B)xs:decimalxs:decimalop:numeric-add(A, B)xs:decimal
fs:plus(A, B)xs:floatxs:floatop:numeric-add(A, B)xs:float
fs:plus(A, B)xs:doublexs:doubleop:numeric-add(A, B)xs:double
fs:plus(A, B)xs:datefn:yearMonthDurationop:add-yearMonthDuration-to-date(A, B)xs:date
fs:plus(A, B)fn:yearMonthDurationxs:dateop:add-yearMonthDuration-to-date(B, A)xs:date
fs:plus(A, B)xs:datefn:dayTimeDurationop:add-dayTimeDuration-to-date(A, B)xs:date
fs:plus(A, B)fn:dayTimeDurationxs:dateop:add-dayTimeDuration-to-date(B, A)xs:date
fs:plus(A, B)xs:timefn:dayTimeDurationop:add-dayTimeDuration-to-time(A, B)xs:time
fs:plus(A, B)fn:dayTimeDurationxs:timeop:add-dayTimeDuration-to-time(B, A)xs:time
fs:plus(A, B)xs:datetimefn:yearMonthDurationop:add-yearMonthDuration-to-dateTime(A, B)xs:dateTime
fs:plus(A, B)fn:yearMonthDurationxs:datetimeop:add-yearMonthDuration-to-dateTime(B, A)xs:dateTime
fs:plus(A, B)xs:datetimefn:dayTimeDurationop:add-dayTimeDuration-to-dateTime(A, B)xs:dateTime
fs:plus(A, B)fn:dayTimeDurationxs:datetimeop:add-dayTimeDuration-to-dateTime(B, A)xs:dateTime
fs:plus(A, B)fn:yearMonthDurationfn:yearMonthDurationop:add-yearMonthDurations(A, B)fn:yearMonthDuration
fs:plus(A, B)fn:dayTimeDurationfn:dayTimeDurationop:add-dayTimeDurations(A, B)fn:dayTimeDuration
fs:minus(A, B)xs:integerxs:integerop:numeric-subtract(A, B)xs:integer
fs:minus(A, B)decimaldecimalop:numeric-subtract(A, B)decimal
fs:minus(A, B)xs:floatxs:floatop:numeric-subtract(A, B)xs:float
fs:minus(A, B)xs:doublexs:doubleop:numeric-subtract(A, B)xs:double
fs:minus(A, B)xs:datexs:datefn:subtract-dates(A, B)fn:dayTimeDuration
fs:minus(A, B)xs:datefn:yearMonthDurationop:subtract-yearMonthDuration-from-date(A, B)xs:date
fs:minus(A, B)xs:datefn:dayTimeDurationop:subtract-dayTimeDuration-from-date(A, B)xs:date
fs:minus(A, B)xs:timexs:timefn:subtract-times(A, B)fn:dayTimeDuration
fs:minus(A, B)xs:timefn:dayTimeDurationop:subtract-dayTimeDuration-from-time(A, B)xs:time
fs:minus(A, B)xs:datetimexs:datetimefn:get-dayTimeDuration-from-dateTimes(A, B)fn:dayTimeDuration
fs:minus(A, B)xs:datetimefn:yearMonthDurationop:subtract-yearMonthDuration-from-dateTime(A, B)xs:dateTime
fs:minus(A, B)xs:datetimefn:dayTimeDurationop:subtract-dayTimeDuration-from-dateTime(A, B)xs:dateTime
fs:minus(A, B)fn:yearMonthDurationfn:yearMonthDurationop:subtract-yearMonthDurations(A, B)fn:yearMonthDuration
fs:minus(A, B)fn:dayTimeDurationfn:dayTimeDurationop:subtract-dayTimeDurations(A, B)fn:dayTimeDuration
fs:times(A, B)xs:integerxs:integerop:numeric-multiply(A, B)xs:integer
fs:times(A, B)xs:decimalxs:decimalop:numeric-multiply(A, B)xs:decimal
fs:times(A, B)xs:floatxs:floatop:numeric-multiply(A, B)xs:float
fs:times(A, B)xs:doublexs:doubleop:numeric-multiply(A, B)xs:double
fs:times(A, B)fn:yearMonthDurationxs:decimalop:multiply-yearMonthDuration(A, B)fn:yearMonthDuration
fs:times(A, B)xs:decimalfn:yearMonthDurationop:multiply-yearMonthDuration(B, A)fn:yearMonthDuration
fs:times(A, B)fn:dayTimeDurationxs:decimalop:multiply-dayTimeDuration(A, B)fn:dayTimeDuration
fs:times(A, B)xs:decimalfn:dayTimeDurationop:multiply-dayTimeDuration(B, A)fn:dayTimeDuration
fs:idiv(A, B)xs:integerxs:integerop:integer-div(A, B)xs:integer
fs:div(A, B)xs:integerxs:integerop:numeric-divide(A, B)xs:double
fs:div(A, B)xs:decimalxs:decimalop:numeric-divide(A, B)xs:decimal
fs:div(A, B)xs:floatxs:floatop:numeric-divide(A, B)xs:float
fs:div(A, B)xs:doublexs:doubleop:numeric-divide(A, B)xs:double
fs:div(A, B)fn:yearMonthDurationxs:decimalop:divide-yearMonthDuration(A, B)fn:yearMonthDuration
fs:div(A, B)fn:dayTimeDurationxs:decimalop:divide-dayTimeDuration(A, B)fn:dayTimeDuration
fs:mod(A, B)xs:integerxs:integerop:numeric-mod(A, B)xs:integer
fs:mod(A, B)xs:decimalxs:decimalop:numeric-mod(A, B)xs:decimal
fs:mod(A, B)xs:floatxs:floatop:numeric-mod(A, B)xs:float
fs:mod(A, B)xs:doublexs:doubleop:numeric-mod(A, B)xs:double
fs:eq(A, B)xs:integerxs:integerop:numeric-equal(A, B)xs:boolean
fs:eq(A, B)xs:decimalxs:decimalop:numeric-equal(A, B)xs:boolean
fs:eq(A, B)xs:floatxs:floatop:numeric-equal(A, B)xs:boolean
fs:eq(A, B)xs:doublexs:doubleop:numeric-equal(A, B)xs:boolean
fs:eq(A, B)xs:booleanxs:booleanop:boolean-equal(A, B)xs:boolean
fs:eq(A, B)xs:stringxs:stringop:numeric-equal(fn:compare(A, B), 1)xs:boolean
fs:eq(A, B)xs:datexs:dateop:date-equal(A, B)xs:boolean
fs:eq(A, B)xs:timexs:timeop:time-equal(A, B)xs:boolean
fs:eq(A, B)xs:dateTimexs:dateTimeop:datetime-equal(A, B)xs:boolean
fs:eq(A, B)fn:yearMonthDurationfn:yearMonthDurationop:yearMonthDuration-equal(A, B)xs:boolean
fs:eq(A, B)fn:dayTimeDurationfn:dayTimeDurationop:dayTimeDuration-equal(A, B)xs:boolean
fs:eq(A, B)GregorianGregorianop:gYear-equal(A, B) etc.xs:boolean
fs:eq(A, B)xs:hexBinaryxs:hexBinaryop:hex-binary-equal(A, B)xs:boolean
fs:eq(A, B)xs:base64Binaryxs:base64Binaryop:base64-binary-equal(A, B)xs:boolean
fs:eq(A, B)xs:anyURIxs:anyURIop:anyURI-equal(A, B)xs:boolean
fs:eq(A, B)xs:QNamexs:QNameop:QName-equal(A, B)xs:boolean
fs:eq(A, B)xs:NOTATIONxs:NOTATIONop:NOTATION-equal(A, B)xs:boolean
fs:ne(A, B)xs:integerxs:integerfn:not(op:numeric-equal(A, B))xs:boolean
fs:ne(A, B)xs:decimalxs:decimalfn:not(op:numeric-equal(A, B))xs:boolean
fs:ne(A, B)xs:floatxs:floatfn:not(op:numeric-equal(A, B))xs:boolean
fs:ne(A, B)xs:doublexs:doublefn:not(op:numeric-equal(A, B))xs:boolean
fs:ne(A, B)xs:booleanxs:booleanfn:not(op:boolean-equal(A, B))xs:boolean
fs:ne(A, B)xs:stringxs:stringfn:not(op:numeric-equal(fn:compare(A, B), 1))xs:boolean
fs:ne(A, B)xs:datexs:datefn:not(op:date-equal(A, B))xs:boolean
fs:ne(A, B)xs:timexs:timefn:not(op:time-equal(A, B))xs:boolean
fs:ne(A, B)xs:dateTimexs:dateTimefn:not(op:datetime-equal(A, B))xs:boolean
fs:ne(A, B)fn:yearMonthDurationfn:yearMonthDurationfn:not(op:yearMonthDuration-equal(A, B))xs:boolean
fs:ne(A, B)fn:dayTimeDurationfn:dayTimeDurationfn:not(op:dayTimeDuration-equal(A, B)xs:boolean
fs:ne(A, B)GregorianGregorianfn:not(op:gYear-equal(A, B)) etc.xs:boolean
fs:ne(A, B)xs:hexBinaryxs:hexBinaryfn:not(op:hex-binary-equal(A, B))xs:boolean
fs:ne(A, B)xs:base64Binaryxs:base64Binaryfn:not(op:base64-binary-equal(A, B))xs:boolean
fs:ne(A, B)xs:anyURIxs:anyURIfn:not(op:anyURI-equal(A, B))xs:boolean
fs:ne(A, B)xs:QNamexs:QNamefn:not(op:QName-equal(A, B))xs:boolean
fs:ne(A, B)xs:NOTATIONxs:NOTATIONxs:not(op:NOTATION-equal(A, B))xs:boolean
fs:gt(A, B)integerintegerop:numeric-greater-than(A, B)xs:boolean
fs:gt(A, B)decimaldecimalop:numeric-greater-than(A, B)xs:boolean
fs:gt(A, B)floatfloatop:numeric-greater-than(A, B)xs:boolean
fs:gt(A, B)doubledoubleop:numeric-greater-than(A, B)xs:boolean
fs:gt(A, B)xs:booleanxs:booleanop:boolean-greater-than(A, B)xs:boolean
fs:gt(A, B)xs:stringxs:stringop:numeric-greater-than(fn:compare(A, B), 0)xs:boolean
fs:gt(A, B)xs:datexs:dateop:date-greater-than(A, B)xs:boolean
fs:gt(A, B)xs:timexs:timeop:time-greater-than(A, B)xs:boolean
fs:gt(A, B)xs:dateTimexs:dateTimeop:datetime-greater-than(A, B)xs:boolean
fs:gt(A, B)fn:yearMonthDurationfn:yearMonthDurationop:yearMonthDuration-greater-than(A, B)xs:boolean
fs:gt(A, B)fn:dayTimeDurationfn:dayTimeDurationop:dayTimeDuration-greater-than(A, B)xs:boolean
fs:lt(A, B)xs:integerxs:integerop:numeric-less-than(A, B)xs:boolean
fs:lt(A, B)xs:decimalxs:decimalop:numeric-less-than(A, B)xs:boolean
fs:lt(A, B)xs:floatxs:floatop:numeric-less-than(A, B)xs:boolean
fs:lt(A, B)xs:doublexs:doubleop:numeric-less-than(A, B)xs:boolean
fs:lt(A, B)xs:booleanxs:booleanop:boolean-less-than(A, B)xs:boolean
fs:lt(A, B)xs:stringxs:stringop:numeric-less-than(fn:compare(A, B), 0)xs:boolean
fs:lt(A, B)xs:datexs:dateop:date-less-than(A, B)xs:boolean
fs:lt(A, B)xs:timexs:timeop:time-less-than(A, B)xs:boolean
fs:lt(A, B)xs:dateTimexs:dateTimeop:datetime-less-than(A, B)xs:boolean
fs:lt(A, B)fn:yearMonthDurationfn:yearMonthDurationop:yearMonthDuration-less-than(A, B)xs:boolean
fs:lt(A, B)fn:dayTimeDurationfn:dayTimeDurationop:dayTimeDuration-less-than(A, B)xs:boolean
fs:ge(A, B)xs:integerxs:integerop:numeric-less-than(B, A)xs:boolean
fs:ge(A, B)xs:decimalxs:decimalop:numeric-less-than(B, A)xs:boolean
fs:ge(A, B)xs:floatxs:floatop:numeric-less-than(B, A)xs:boolean
fs:ge(A, B)xs:doublexs:doubleop:numeric-less-than(B, A)xs:boolean
fs:ge(A, B)xs:stringxs:stringop:numeric-greater-than(fn:compare(A, B), -1)xs:boolean
fs:ge(A, B)xs:datexs:dateop:date-less-than(B, A)xs:boolean
fs:ge(A, B)xs:timexs:timeop:time-less-than(B, A)xs:boolean
fs:ge(A, B)xs:dateTimexs:dateTimeop:datetime-less-than(B, A)xs:boolean
fs:ge(A, B)fn:yearMonthDurationfn:yearMonthDurationop:yearMonthDuration-less-than(B, A)xs:boolean
fs:ge(A, B)fn:dayTimeDurationfn:dayTimeDurationop:dayTimeDuration-less-than(B, A)xs:boolean
fs:le(A, B)xs:integerxs:integerop:numeric-greater-than(B, A)xs:boolean
fs:le(A, B)xs:decimalxs:decimalop:numeric-greater-than(B, A)xs:boolean
fs:le(A, B)xs:floatxs:floatop:numeric-greater-than(B, A)xs:boolean
fs:le(A, B)xs:doublexs:doubleop:numeric-greater-than(B, A)xs:boolean
fs:le(A, B)xs:stringxs:stringop:numeric-less-than(fn:compare(A, B), 1)xs:boolean
fs:le(A, B)xs:datexs:dateop:date-greater-than(B, A)xs:boolean
fs:le(A, B)xs:timexs:timeop:time-greater-than(B, A)xs:boolean
fs:le(A, B)xs:dateTimexs:dateTimeop:datetime-greater-than(B, A)xs:boolean
fs:le(A, B)fn:yearMonthDurationfn:yearMonthDurationop:yearMonthDuration-greater-than(B, A)xs:boolean
fs:le(A, B)fn:dayTimeDurationfn:dayTimeDurationop:dayTimeDuration-greater-than(B, A)xs:boolean

C References

C.1 Normative References

XML
World Wide Web Consortium. Extensible Markup Language (XML) 1.0 (Second edition), October, 2000 See http://www.w3.org/TR/REC-xml.
XML Names
World Wide Web Consortium. Namespaces in XML. W3C Recommendation. See http://www.w3.org/TR/REC-xml-names/ .
XML Path Language (XPath) 2.0
World Wide Web Consortium. XML Path Language (XPath) 2.0. W3C Working Draft, 15 November 2002. See http://www.w3.org/TR/xpath20/.
XML Schema Part 1
World Wide Web Consortium. XML Schema Part 1 : Structures. W3C Recommendation, May 2001. See http://www.w3.org/TR/xmlschema-1/
XML Schema Part 2
World Wide Web Consortium. XML Schema Part 2 : Datatypes. W3C Recommendation, May 2001. See http://www.w3.org/TR/xmlschema-2/.
XQuery 1.0: A Query Language for XML
World Wide Web Consortium.XQuery 1.0: A Query Language for XML. W3C Working Draft, 15 November 2002. See http://www.w3.org/TR/xquery/
XQuery 1.0 and XPath 2.0 Data Model
World Wide Web Consortium. XQuery 1.0 and XPath 2.0 Data Model. W3C Working Draft, 15 November 2002. See http://www.w3.org/TR/query-datamodel/.
XQuery 1.0 and XPath 2.0 Functions and Operators
World Wide Web Consortium. XQuery 1.0 and XPath 2.0 Functions and Operators. W3C Working Draft, 15 November 2002. See http://www.w3.org/TR/xquery-operators/

C.2 Non-normative References

XML Path Language (XPath) : Version 1.0
World Wide Web Consortium. XML Path Language (XPath) : Version 1.0. W3C Recommendation, November, 1999. See http://www.w3.org/TR/xpath.html.
XML Query 1.0 Requirements
World Wide Web Consortium. XML Query 1.0 Requirements. W3C Working Draft, 15 Feb 2001. See http://www.w3.org/TR/xmlquery-req.
XML Query Use Cases
World Wide Web Consortium. XML Query Use Cases. W3C Working Draft, 20 Dec 2001. See http://www.w3.org/TR/xmlquery-use-cases/.
XML Schema : Formal Description
World Wide Web Consortium. XML Schema: Formal Description. W3C Working Draft, March 2001. See http://www.w3.org/TR/xmlschema-formal/
XML Schema Part 0
World Wide Web Consortium. XML Schema Part 0 : Primer. W3C Recommendation, May 2001. See http://www.w3.org/TR/xmlschema-0/
XSLT 99
World Wide Web Consortium. XSL Transformations (XSLT), Version 1.0. W3C Recommendation, November 1999. See http://www.w3.org/TR/xslt.

C.3 Background References

BFS00
P. Buneman, M. Fernandez, D. Suciu. UnQL: A query language and algebra for semistructured data based on structural recursion. VLDB Journal, April, 2000, Vol 9, Number 1.
BKD90
Francois Bancilhon, Paris Kanellakis, Claude Delobel. Building an Object-Oriented Database System. Morgan Kaufmann, 1990.
BNTW95
Peter Buneman, Shamim Naqvi, Val Tannen, Limsoon Wong. Principles of programming with complex object and collection types. Theoretical Computer Science 149(1):3--48, 1995.
CM93
S. Cluet and G. Moerkotte. Nested queries in object bases. Workshop on Database Programming Languages, pages 226--242, New York, August 1993.
Col90
L. S. Colby. A recursive algebra for nested relations. Information Systems 15(5):567-582, 1990.
Graefe93
Goetz Graefe, Query Evaluation Techniques for Large Databases. In ACM Computing Surveys, 25(2):73--170, 1993.
HP2000
Haruio Hosoya, Benjamin Pierce, XDuce : A Typed XML Processing Language (Preliminary Report) WebDB Workshop 2000.
Languages
Handbook of Formal Languages. G. Rozenberg and A. Salomaa, editors. Springer-Verlag. 1997.
LMW96
Leonid Libkin, Rona Machlin, and Limsoon Wong. A query language for multi-dimensional arrays: Design, implementation, and optimization techniques. SIGMOD 1996.
LW97
Leonid Libkin and Limsoon Wong. Query languages for bags and aggregate functions. Journal of Computer and Systems Sciences, 55(2):241--272, October 1997.
Milner
R. Milner, M. Tofte, R. Harper, D. MacQueen The Definition of Standard ML (Revise). MIT Press, 1997.
Mitchell
John C. Mitchell Foundations for Programming Languages. MIT Press, 1998.
Mog89
E. Moggi, Computational lambda-calculus and monads. In Symposium on Logic in Computer Science Asilomar, California, IEEE, June 1989.
Mog91
E. Moggi, Notions of computation and monads. Information and Computation, 93(1), 1991.
ODMG
Rick Cattell et al. The Object Database Standard: ODMG-93, Release 1.2. Morgan Kaufmann Publishers, San Francisco, 1996.
Quilt
Don Chamberlin, Jonathan Robie, and Daniela Florescu. Quilt: An XML Query Language for Heterogeneous Data Sources. International Workshop on the Web and Databases (WebDB'2000), Dallas, Texas, May 2000.
SQL
International Organization for Standardization (ISO). Information Technology-Database Language SQL. Standard No. ISO/IEC 9075:1999. (Available from American National Standards Institute, New York, NY 10036, (212) 642-4900.)
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.
Wad93
P. Wadler, Monads for functional programming. In M. Broy, editor, Program Design Calculi, NATO ASI Series, Springer Verlag, 1993. Also in J. Jeuring and E. Meijer, editors, Advanced Functional Programming, LNCS 925, Springer Verlag, 1995.
Wad95
P. Wadler, How to declare an imperative. ACM Computing Surveys, 29(3):240--263, September 1997.
Won00
Limsoon Wong. An introduction to the Kleisli query system and a commentary on the influence of functional programming on its implementation. Journal of Functional Programming, to appear.
XMLQL99
A. Deutsch, M. Fernandez, D. Florescu, A. Levy, and D. Suciu. A query language for XML. In International World Wide Web Conference, 1999.
XQL99
J. Robie, editor. XQL '99 Proposal, 1999. See http://www.ibiblio.org/xql/xql-proposal.html.
YAT99
S. Cluet, and J. Siméon. YATL: A Functional and Declarative Language for XML. See http://db.bell-labs.com/user/simeon/icfp.ps

D Issues

D.1 Introduction

The issues in [D.2 Issues list] serve as a design history for this document. The ordering of issues is irrelevant. Each issue has a unique id of the form Issue-<dddd> (where d is a digit). This can be used for referring to the issue by <url-of-this-document>#Issue-<dddd>. Furthermore, each issue has a mnemonic header, a date, an optional description, and an optional resolution. For convenience, resolved issues are displayed in green. Some of the descriptions of the resolved issues are obsolete w.r.t. to the current version of the document.

Ed. Note: Peter (Aug-05-2000): For the sake of archival, there are some duplicate issues raised in multiple instances. Duplicate issues are marked as "resolved" with reference to the representative issue.

D.2 Issues list

Issue-0001:  Attributes

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  One example of the need for support of [Issue-0049:  Unordered Collections], but also: Attributes need to be constrained to contain white space separated lists of simple types only.

Resolution:  Attributes are represented by attribute attribute-name { content }.

Issue-0002:  Namespaces

Date: Jul-26-2000
Raised by: Algebra Editors

Resolution:  Namespaces are represented by {uri-of-namespace}localname.

Issue-0003:  Document Order

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  The data model and algebra do not define a global order on documents. Querying global order is often required in document-oriented queries.

Resolution:  Resolved by adding < operator defined on nodes in same document. See [Issue-0079:  Global order between nodes in different documents] for order between nodes in different documents.

Issue-0004:  References vs containment

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  The query-algebra datamodel currently does not explicitly model children-elements by references (other than the XML-Query Datamodel. This facilitates presentation, but may be an oversimplification with regard to [Issue-0005:  Element identity].

Resolution:  This issue is resolved by subsumption as follows: (1) All child-elements are (implicit) references to nodes. (2) Thus, having resolved [Issue-0005:  Element identity] this issue is resolved too.

Issue-0005:  Element identity

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  Do expressions preserve element identity or don't they? And does "=" and distinct use comparison by reference or comparison by value?

Resolution:  The first part of the question has been resolved by resolution of [Issue-0010:  Construct values by copy]. The second part raises a more specific issue [Issue-0066:  Shallow or Deep Equality?].

Issue-0006:  Source and join syntax instead of "for"

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  Another term for "source and join syntax" is "comprehension".

Resolution:  This issue is resolved by subsumption under [Issue-0021:  Syntax]. List comprehension is a syntactic alternative to "for v in e1 do e2", which has been favored by the WG in the resolution of [Issue-0021:  Syntax].

Issue-0007:  References: IDREFS, Keyrefs, Joins

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  Currently, the Algebra does not support reference values, such as IDREF, or Keyref (not to be mixed up with "node-references" - see [Issue-0005:  Element identity], which are defined in the XML Query Data Model. The Algebra's type system should be extended to support reference types and the data model operators ref, and deref should be supported (similar to id() in XPath).

Resolution:  Delegated to XPath 2.0. Algebra should adopt solutions (e.g., id()/keyref() functions) provided in XPath 2.0. There may be an interaction between IDREFs and RefNodes, but we're not going to cover that now.

Issue-0008:  Fixed point operator or recursive functions

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  It may be useful to add a fixed-point operator, which can be used in lieu of recursive functions to compute, for example, the transitive closure of a collection.

Currently, the Algebra does not guarantee termination of recursive expressions. In order to ensure termination, we might require that a recursive function take one argument that is a singleton element, and any recursive invocation should be on a descendant of that element; since any element has a finite number of descendants, this avoids infinite regress. (Ideally, we should have a simple syntactic rule that enforces this restriction, but we have not yet devised such a rule.)

Impacts optimization; hard to do static type inference; current algebra is first-order

Resolution:  The functionality described is appropriately covered by the use of recursive functions. XQuery is a functional language and does not provide a fixed-point operator in its current version.

Issue-0009:  Externally defined functions

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  There is no explicit support for externally defined functions.

The set of built-in functions may be extended to support other important operators.

Resolution:  Algebra editors endorse a solution that uses XP for specifying signatures of external functions. Algebra will adopt solution provided by [XPath/XQuery].

Issue-0010:  Construct values by copy

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  Need to be able to construct new types from bits of old types by reference and by copy. Related to [Issue-0005:  Element identity].

Resolution:  The WG wishes to support both: construction of values by copy, as well as references to original nodes. This needs some further investigation to sort out all technical difficulties (see [Issue-0062:  Open questions for constructing elements by reference]) so the change has not yet been reflected in the Algebra document.

Issue-0011:  XPath tumbler syntax instead of index?

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  XPath provides as a shorthand syntax [integer] to select child-elements by their position on the sibling axes, whereas the xml-query algebra uses a combination of a built-in function index() and iteration.

Addendum by JS (submitted by MF) Dec 19/2000: The typing of index is lossy : it produces a factored type. Jerome suggests the more precise range operator:

e : q min m  max n   n' - (m'-1) = r  m' >= m   n' <= n
-----------------------------------------------
            range(e;m';n') : q min r  max r

nth(e;n) == range(e;n;n)

The range operator takes a repetition of prime types and those values in the range m' to n'; if the repetition does not include that range, a run-time error is raised. The range and nth operators could also be defined in terms of head and tail and polymorphic recursive functions. In the absence of parameteric polymorphism, it is not possible to define range and nth with precise types.

Here are Peter's rules:

e : p min m  max n     n!=* 
-------------------------------------------------
range(e;m';n') : p{n'-max(m,m')+1,min(n',n)-m'+1}

For example:
let v1 = a[] min 2  max 4

range(v1;3;3): a[] min 1  max 1
range(v1;1;3): a[] min 2  max 3
range(v1;3;5): a[] min 1  max 2
range(v1;1;5): a[] min 2  max 4

e : p min m  max * 
-----------------------------
range(e;m';n') : p min 0  max n'-m'+1

let v2 = a[] min 0  max *

range(v2;1;3): a[] min 0  max 2

this follows the typical semantics for head() and tail():
head(()) = tail(()) = ()
and the semantics behind
range(e;m',n') = tail o ...(m' times)   ... o tail o head,
                 tail o ...(m'+1 times) ... o tail o head,
                 ...
                 tail o ...(n' times)   ... o tail o head

I would have no troubles in restricting ourselves to nth() instead of range() in the algebra (range can always be enumerated by nth()). Furthermore, we should consider whether m',n' can be computed numbers.

Issue-0012:  GroupBy - needs second order functions?

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  The type system is currently first order: it does not support function types nor higher-order functions. Higher-order functions are useful for specifying, for example, sorting and grouping operators, which take other functions as arguments.

Resolution:  The WG has decided to express groupBy by a combination of for and distinct. Thus w.r.t. to GroupBy this Issue is resolved. Because GroupBy is not the only use case for higher order functions, a new issue [Issue-0063:  Do we need (user defined) higher order functions?] is raised.

Issue-0013:  Collations

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  Collations identify the ordering to be applied for sorting strings. Currently, it is considered to have an (optional parameter) collation "name" as follows: "SORT variable IN exp BY +(expression {ASCENDING|DESCENDING} {COLLATION name}). An alternative would be to model a collation as a simple type derived from string, and use type-level casting, i.e. expression :collationtype (which is already supported in the XML Query Algebra), for specifying the collation. That would make: "SORT variable IN exp BY +(expression:collationname {ASCENDING|DESCENDING}). But that requires some support from XML-Schema.

More generally, collations are important for any operator in the Algebra that involves string comparison, among them: sort, distinct, "=" and "<".

Resolution:  Formal semantics will adopt solution provided by Operators.

Issue-0014:  Polymorphic types

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  The type system is currently monomorphic: it does not permit the definition of a function over generalized types. Polymorphic functions are useful for factoring equivalent functions, each of which operate on a fixed type.

The current type system has already a built-in polymorphic type (lists) and is likely to have more (unordered collections). The question is, whether to allow for user-defined polymorphic types and user defined polymorphic functions.

Resolution:  It has been decided this feature was not required for XQuery 1.0.

Issue-0015:  3-valued logic to support NULLs

Date: Jul-26-2000
Raised by: Algebra Editors

Resolution:  The Formal Semantics supports the current semantics of NULL values, as described in the XQuery December working draft. The Formal Semantics will reflect further resolution of open issues on NULLs and 3 valued logic as decided by XQuery.

Issue-0016:  Mixed content

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  The XML-Query Algebra allows to generate elements with an arbitrary mixture of data (of simple type) and elements. XML-Schema only allows for a combination of strings interspersed with elements (aka mixed content). We need to figure out whether and how to constrain the XML-Query Algebra accordingly (e.g. by typing rules?)

Resolution:  The type system has been extended to support the interleaving operator & - see [3 The XQuery type system]. Mixed content is defined in terms of &.

Issue-0017:  Unordered content

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  All-groups in XML-Schema, not to be mixed up with [Issue-0049:  Unordered Collections]

Resolution:  The type system has been extended with the support of all-groups - see [3 The XQuery type system].

Issue-0018:  Align algebra types with schema

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  The Algebra's internal type system is the type system of XDuce. A potentially significant problem is that the Algebra's types may lose information when converted into XML Schema types, for example, when a result is serialized into an XML document and XML Schema.

James Clark points out : "The definition of AnyComplexType doesn't match the concrete syntax for types since it applies unbounded repetition to AnyTree and one alternative for AnyTree is AnyAttribute." This is another example of an alignment issue.

This issue comprises also issues [Issue-0016:  Mixed content], [Issue-0017:  Unordered content], [Issue-0053:  Global vs. local elements], [Issue-0054:  Global vs. local complex types], [Issue-0019:  Support derived types], substitution groups.

Resolution:  Closed by the semantics of named typing. See Sections 3 and 7 of the Formal Semantics document.

Issue-0019:  Support derived types

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  The current type system does not support user defined type hierarchies (by extension or by restriction).

Resolution:  Closed by the semantics of named typing. Derived types are now supported in the type system. See Sections 3 and 7 of the Formal Semantics document.

Issue-0020:  Structural vs. name equivalence

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  The subtyping rules in [3.4.3 Subtype] only define structural subtyping. We need to extend this with support for subtyping via user defined type hierarchies - this is related to [Issue-0019:  Support derived types].

Resolution:  Closed by the semantics of named typing. The Formal Semantics now support both named and structural typing. See Sections 3 and 7 of the Formal Semantics document.

Issue-0021:  Syntax

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  (e.g. for.<-.in vs for.in.do)

Resolution:  The WG has voted for several syntax changes , "for v in e do e", "let v = e do", "sort v in e by e ...", "distinct", "match case v:t e ... else e".

Issue-0022:  Indentation, Whitespaces

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  Is indentation significant?

Resolution:  The WG has consensus that indentation is not significant , i.e., all documents are white space normalized.

Issue-0023:  Catch exceptions and process in algebra?

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  Does the Algebra give explicit support for catching exceptions and processing them?

Resolution:  Subsumed by new issue [Issue-0064:  Error code handling in Query Algebra].

Issue-0024:  Value for empty sequences

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  What does "value" do with empty sequences?

Resolution:  The definition of value(e) has changed to:

value(e) = typeswitch children(e)
                     case v: AnyScalar do v
                     else()

Furthermore, the typing rules for "for v in e1 do e2" have been changed such that the variable v is typed-checked seperately for each unit-type occuring in expression e1.

Consequently the following example would be typed as follows:

query for b in b0/book do
      value(b/year): xs:integer min 0 max *

rather than leading to an error.

Issue-0025:  Treatment of empty results at type level

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  This is related to [Issue-0024:  Value for empty sequences].

Resolution:  Resolved by resolution of [Issue-0025:  Treatment of empty results at type level].

Issue-0026:  Project - one tag only

Date: Jul-26-2000
Raised by: Algebra Editors

Description:  Project is only parameterized by one tag. How can we translate a0/(b | c)?

Resolution:  With the new syntax (and type system) a0/(b | c) can be translated to "for v in a0 do typeswitch case v1:b[AnyType] do v1 case v2:c[AnyType] do c else ()".

Issue-0027:  Case syntax

Date: Jul-26-2000
Raised by: Quilt Comments et al.

Description:  N-ary case can be realized by nested binary cases.

Resolution:  New (n-ary) case syntax is introduced.

Issue-0028:  Fusion

Date: Jul-26-2000
Raised by: Michael Rys

Description:  Does the Algebra support fusion as introduced by query languages such as LOREL? This is related to [Issue-0005:  Element identity], because fusion only makes sense with support of element identity.

Resolution:  Fusion is equivalent to 'natural full-outer join'. [XPath/XQuery] can reraise issue if desired. If added, the Algebra editors should review any solution w.r.t typing.

Issue-0029:  Views

Date: Jul-26-2000
Raised by: Michael Rys

Description:  One of the problems in views: Can we undeclare/hide things in environment? For example, if we support element-identity, can we explicitly discard a parent, and/or children from an element in the result-set? Related to [Issue-0005:  Element identity].

Resolution:  [XPath/XQuery] can reraise issue if desired. If added, the Algebra editors should review any solution w.r.t typing.

Issue-0030:  Automatic type coercion

Date: Jul-26-2000
Raised by: Dana Florescu

Description:  What do we do if a value does not have a type or a different type from what is required?

Suggested Resolution:  We believe that the XML Query Language should specify default type coercions for mixed mode arithmetic should be performed according to a fixed precedence hierarchy of types, specifically integer to fixed decimal, fixed decimal to float, float to double. This policy has the advantage of simplicity, tradition, and static type inference. Programmers could explicitly specify alternative type coercions when desirable.

Resolution:  Delegation to XPath 2.0, [XPath/XQuery], and/or Operators.

Issue-0031:  Recursive functions

Date: Jul-26-2000
Raised by: Dana Florescu

Resolution:  subsumed by [Issue-0008:  Fixed point operator or recursive functions]

Issue-0032:  Full regular path expressions

Date: Jul-26-2000
Raised by: Dana Florescu

Description:  Full regular path expressions allow to constrain recursive navigation along paths by means of regular expressions, e.g. a/b*/c denotes all paths starting with an a, proceeding with arbitrarily many b's and ending in a c. Currently the XML-Query Algebra can express this by means of (structurally) recursive functions. An alternative may be the introduction of a fixpoint operator [Issue-0008:  Fixed point operator or recursive functions].

Resolution:  XPath 2.0 can raise issue if desired. The Algebra editors should review any solution w.r.t typing.

Issue-0033:  Metadata Queries

Date: Jul-26-2000
Raised by: Dana Florescu

Description:  Metadata queries are queries that require runtime access to type information.

Resolution:  Metadata queries are believed to be appropriately covered by XQuery 1.0 (e.g., using typeswitch).

Issue-0034:  Fusion

Date: Jul-26-2000
Raised by: Dana Florescu

Resolution:  Identical with [Issue-0028:  Fusion]

Issue-0035:  Exception handling

Date: Jul-26-2000
Raised by: Dana Florescu

Resolution:  Subsumed by [Issue-0023:  Catch exceptions and process in algebra?] and [Issue-0064:  Error code handling in Query Algebra].

Issue-0036:  Global-order based operators

Date: Jul-26-2000
Raised by: Dana Florescu

Resolution:  Subsumed by [Issue-0003:  Document Order]

Issue-0037:  Copy vs identity semantics

Date: Jul-26-2000
Raised by: Dana Florescu

Resolution:  subsumed by [Issue-0005:  Element identity]

Issue-0038:  Copy by reachability

Date: Jul-26-2000
Raised by: Dana Florescu

Description:  Is it possible to copy children as well as IDREFs, Links, etc.? Related to [Issue-0005:  Element identity] and [Issue-0008:  Fixed point operator or recursive functions]

Resolution:  Resolved by addition of "deep" copy operator in [XQuery 1.0 and XPath 2.0 Data Model].

Issue-0039:  Dereferencing semantics

Date: Jul-26-2000
Raised by: Dana Florescu

Resolution:  Subsumed by [Issue-0005:  Element identity]

Issue-0040:  Case Syntax

Date: Aug-01-2000
Raised by: Quilt

Description:  We suggest that the syntax for "case" be made more regular. At present, it takes only two branches, the first labelled with a tag-name and the second labelled with a variable. A more traditional syntax for "case" would have multiple branches and label them in a uniform way. If the algebra is intended only for semantic specification, "case" may not even be necessary.

Resolution:  subsumed by [Issue-0027:  Case syntax]

Issue-0041:  Sorting

Date: Aug-01-2000
Raised by: Quilt

Description:  We are not happy about the three-step sorting process in the Algebra. We would prefer a one-step sorting operator such as the one illustrated below, which handles multiple sort keys and mixed sorting directions: SORT emp <- employees BY emp/deptno ASCENDING emp/salary DESCENDING

Resolution:  The WG has decided to go for the above syntax, with an (optional) indication of COLLATION.

Issue-0042:  GroupBy

Date: Aug-01-2000
Raised by: Quilt

Description:  We do not think the algebra needs an explicit grouping operator. Quilt and other high-level languages perform grouping by nested iteration. The algebra can do the same.

related to [Issue-0012:  GroupBy - needs second order functions?]

Resolution:  The WG has decided to skip groupBy for the time being.

Issue-0043:  Recursive Descent for XPath

Date: Aug-01-2000
Raised by: Quilt

Description:  The very important XPath operator "//" is supported in the Algebra only by writing a recursive function. This is adequate for a semantic specification, but if the Algebra is intended as an optimizable target language it will need better support for "//" (possibly in the form of a fix-point operator.)

Resolution:  Resolved by subsumption under [Issue-0043:  Recursive Descent for XPath]

Issue-0044:  Keys and IDREF

Date: Aug-01-2000
Raised by: Quilt

Description:  We think the algebra needs some facility for dereferencing keys and IDREFs (exploiting information in the schema.)

Resolution:  Subsumed by [Issue-0007:  References: IDREFS, Keyrefs, Joins]

Issue-0045:  Global Order

Date: Aug-01-2000
Raised by: Quilt

Description:  We are concerned about absence of support for operators based on global document ordering such as BEFORE and AFTER.

Resolution:  Subsumed by [Issue-0003:  Document Order]

Issue-0046:  FOR Syntax

Date: Aug-01-2000
Raised by: Quilt

Description:  We agree with comments made in the face-to-face meeting about the aesthetics of the Algebra's syntax for iteration. For example, the following syntax is relatively easy to understand: FOR x IN some_expr EVAL f(x) whereas we find the current algebra equivalent to be confusing and misleading: FOR x <- some_expr IN f(x) This syntax appears to assign the result of some_expr to variable x, and uses the word IN in a non-intuitive way.

Resolution:  Subsumed by [Issue-0021:  Syntax]

Issue-0047:  Attributes

Date: Aug-01-2000
Raised by: Quilt

Description:  See [Issue-0001:  Attributes].

Resolution:  Subsumed by [Issue-0001:  Attributes]

Issue-0048:  Explicit Type Declarations

Date: Jul-27-2000
Raised by: Group 1 at F2F, Redmond

Description:  Type Declaration for the results of a query: The issue is whether to auto construct the result type from a query or to pre-declare the type of the result from a query and check for correct type on the return value. Suggestion: Support for pre-declared result data type and as well as to coerce the output to a new type is desirable. Runtime or compile time type checking is to be resolved? Once you attach a name to a type, it is preserved during the query processing.

Resolution:  W.r.t. compile time type casts this is already possible with e:t. For run-time casts an issue has been raised in [Issue-0062:  Open questions for constructing elements by reference].

Issue-0049:  Unordered Collections

Date: Jul-27-2000
Raised by: Algebra Editors, Group 1, F2F, Redmond

Description:  Currently, all sequences in the data model are ordered. It may be useful to have unordered forests. The distinct-node function, for example, produces an inherently unordered forest. Unordered forests can benefit from many optimizations for the relational algebra, such as commutable joins.

Handling of collection of attributes is easy but the collection of elements is complex due to complex type support for the elements. It makes sense to allow casting from unordered to ordered collection and vice versa. It is not clear whether the new ordered or unordered collection is a new type or not. It affects function resolution, optimization.

Our request to Schema to represent insignificance of ordering at schema level has not been fulfilled. Thus we need to be aware that this information may get lost, when mapping to schema.

Resolution:  Unordered collections are described by {t} see [3 The XQuery type system], some operators (sort, distinct-node, for, and sequence) are overloaded, and some operators (difference, intersection) are added). A new issue [Issue-0076:  Unordered types] is raised.

Issue-0050:  Recursive Descent for XPath

Date: Jul-27-2000
Raised by: Group 1, F2F, Redmond

Description:  Suggestion: The group likes to add a support for fixed-point operator in the query language that will allow us to express the semantics of the // operator in an xpath expression. A path expression of the form a//b may be represented by a fixed-point operator fp(a, "/.")/b.

Resolution:  Subsumed by [Issue-0043:  Recursive Descent for XPath]

Issue-0051:  Project redundant?

Date: Aug-05-2000
Raised by: Peter Fankhauser

Description:  It appears that project a e could be reduced to sth. like

for v <- e in case v of a[v1] =>
        a[v1] | v2 => ()

... or would that generate a less precise type?

Resolution:  With the new type system and handling of the for operator, project is indeed redundant.

Issue-0052:  Axes of XPath

Date: Aug-05-2000
Raised by: Peter Fankhauser

Description:  The current algebra makes navigation to parents difficult to impossible. With support of Element Identity [Issue-0005:  Element identity] and recursive functions [Issue-0008:  Fixed point operator or recursive functions] one can express parent() by a recursive function via the document root. More direct support needs to be investigated w.r.t its effect on the type system.

The WG wishes to support a built-in operator parent().

Resolution:  XPath 2.0 and [XPath/XQuery] can reraise issue if desired. Algebra should review any solution w.r.t typing. Question: whether namespace axis (i.e., access namespace nodes) will be included in [XPath/XQuery]. Algebra currently has issues related to typing of parent() and descendant(). If sibling axes are included in [XPath/XQuery], then Algebra should review w.r.t. typing.

Issue-0053:  Global vs. local elements

Date: Aug-05-2000
Raised by: Peter Fankhauser

Description:  The current type system cannot represent global element-declarations of XML-Schema. All element declarations are local.

Resolution:  The type system now supports both local and global elements and attributes.

Issue-0054:  Global vs. local complex types

Date: Aug-05-2000
Raised by: Peter Fankhauser

Description:  The current type system does not distinguish between global and local types as XML-Schema does. All types appear to be fully nested (i.e. local types)

Resolution:  The type system now supports both local and global types.

Issue-0055:  Types with non-wellformed instances

Date: Aug-05-2000
Raised by: Peter Fankhauser

Description:  The type system and algebra allows for sequences of simple types, which can usually be not represented as a well-formed document. How shall we constrain this? Related to [Issue-0016:  Mixed content].

Resolution:  XQuery 1.0 supports non-well-formed heterogeneous sequences for intermediate results. The XQuery type system supports a way to type such intermediate results.

Issue-0056:  Operators on Simple Types

Date: Jul-15-2000
Raised by: Fernandez et al.

Description:  We intentionally did not define equality or relational operators on element and simple type. These operators should be defined by consensus.

Resolution:  [XPath/XQuery] formal semantics adopts solution provided by Operators task force.

Issue-0057:  More precise type system; choice in path

Date: Aug-07-2000
Raised by: LA-Team

Description:  (This subsumes [Issue-0051:  Project redundant?]). If the type system were more precise, then (project a e) could be replaced by:

for v &lt;- e in
    case v of
      a[v1] =&gt; a[v1]
    | v2 =&gt; ()

One could also represent (e/(a|b)) directly in a similar style.

for v &lt;- e in
    case v of
      a[v1] =&gt; a[v1]
    | v2 =&gt; case v2 of
      b[v3] =&gt; b[v3]
            | v4 =&gt; ()

Currently, there is no way to represent (e/(a|b)) without loss of precision, so if we do not change the type system, we may need to have some way to represent (e/(a|b)) and similar terms without losing precision. (The LA team has a design for this more precise type system, but it is too large to fit in the margin of this web page!)

Resolution:  See resolution of [Issue-0051:  Project redundant?]

Issue-0058:  Downward Navigation only?

Date: Aug-07-2000
Raised by: LA-Team

Description:  Related to [Issue-0052:  Axes of XPath]. The current type system (and the more precise system alluded to in [Issue-0057:  More precise type system; choice in path]) seems well suited for handling XPath children and descendant axes, but not parent, ancestor, sibling, preceding, or following axes. Is this limitation one we can live with?

Resolution:  Subsumed by [Issue-0052:  Axes of XPath]

Issue-0059:  Testing Subtyping

Date: Aug-07-2000
Raised by: LA-Team

Description:  One operation required in the Algebra is to test whether XML type t1 is a subtype of XML type t2, indicated by writing t1 <: t2. There is a well-known algorithm for this, based on tree automata, which is a straightforward variant of the well-known algorithm for testing whether the language generated by one regular-expression is a subset of the language generated by another. (The algorithm involves generating deterministic automata for both regular expressions or types.)

However, the naive implementation of the algorithm for comparing XML types can be slow in practice, whereas the naive algorithm for regular expressions is tolerably fast. The only acceptably fast implementation of a comparison for XML types that the LA team knows of has been implemented by Haruo Hasoya, Jerome Voullion, and Benjamin Pierce at the University of Pennsylvania, for their implementation of Xduce. (Our implementation of the Algebra re-uses their code, with permission.)

So, should we adopt a simpler definition of subtyping which is easier to test? One possibility is to adopt the sibling restriction from Schema, which requires that any two elements which appear a siblings in the same content model must themselves have contents of the same type. Jerome Simeon and Philip Wadler discovered that adopting the sibling restriction reduces the problem of checking subtyping of XML types to that of checking regular languages for inclusion, so it may be worth adopting the restriction for that reason.

Resolution:  With pure named typing, subtyping can be checked using standard finite state automatas.

Issue-0060:  Internationalization aspects for strings

Date: Jun-26-2000
Raised by: I18N

Description:  These issues are taken from the comments on the Requirements Document by I18N

Further information can be found at http://www.w3.org/TR/WD-charreq.

It is a goal of i18n that queries involving string matching ("select x where x='some_constant'") treat canonically equivalent strings (in the Unicode sense) as matching. If the query and the target are both XML, early normalization (as per the Character Model) is assumed and binary comparison ensures that the equivalence requirement is satisfied. However, if the target is originally a legacy database which logically has a layer that exports the data as XML, that XML must be exported in normalized form. The XML Query spec must impose the normalization requirement upon such layers.

Similarly, the query may come from a user-interface layer that creates the XML query. The XML Query spec must impose the normalization requirement upon such layers.

Provided that the query and the target are in normalized form C, the output of the query must itself be in normalized form C.

Queries involving string matching should support various kinds of loose matching (such as case-insensitivity, katakana-hiragana equivalence, accent-accentless equivalence, etc.)

If such features as case-insensitivity are present in queries involving string matching, these features must be properly internationalized (e.g. case folding works for accented letters) and language-dependence must be taken into account (e.g. Turkish dotless-i).

Queries involving character counting and indexing must take into account the Character Model. Specifically, they should follow Layer 3 (locale-independent graphemes). Additional details can be found in The Unicode Standard 3.0 and UTR#18. Queries involving word counting and indexing should similarly follow the recommendations in these references.

Resolution:  [XPath/XQuery] formal semantics adopts solution provided by Operators task force.

Issue-0061:  Model for References

Date: Aug-16-2000
Raised by: Group 3, F2F, Redmond

Description:  Related to a number of issues around [Issue-0005:  Element identity].

  • Use Cases

    Table of Contents

    REF *could* do this well if it were restructured - it does not maintain unforeseen relationships or use them...

    Bibliographies

    Recursive parts

    RDF assertions

    Inversion of simple parent/child references (related to [Issue-0058:  Downward Navigation only?]).

  • What can we leave out?

    can we leave out transitive closure?

    can we limit recursion?

    can we leave out fixed point recursion?

    related to [Issue-0008:  Fixed point operator or recursive functions]

  • Do we need to be able to...

    a. Find the person with the maximum number of descendants?

    b. Airplane routes: how can I get from RDU to Raleigh? (fixed point: guaranteeing termination in reasonable time...)

    c. Given children and their mothers, can I get mothers and their children? (without respect to the form of the original reference...)

    related to [Issue-0008:  Fixed point operator or recursive functions].

  • Should we abstract out the difference between different kinds of references? If so, should we be able to cast to a particular kind of reference in the output?

    a. abstracting out the differences is cheaper, which is kewl...

    b. the kind of reference gives me useful information about: locality (same document, same repository, big bad internet...) static vs. dynamic (xpointer *may* be resolved dynamically, or *may* be resolved at run time, ID/IDREF is static).

    related to [Issue-0007:  References: IDREFS, Keyrefs, Joins].

  • do we need to be able to generate ids, e.g. using skolem functions?

    for a document in RAM, or in a persistent tree, identity may be present, implicit, system dependent, and cheap - it's nice to have an abstraction that requires no more than the implicit identity

    persistable ID is more expensive, may want to be able to serialize with ID/IDREF to instantiate references in the data model

    can use XPath instead of generating ID/IDREF, but these references are fragile, and one reason for queries is to create data that may be processed further

    persistable ID unique within a repository context

    persistable ID that is globally unique

    related to [Issue-0005:  Element identity].

  • copy vs. reference semantics

    "MUST not preclude updates..."

    in a pure query environment, sans update, we do not need to distinguish these

    if we have update, we may need to distinguish, perhaps in a manner similar to "updatable cursors" in SQL

    programs may do queries to get DOM nodes that can that be modified. It is essential to be able to distinguish copies of nodes from the nodes themselves.

    copy semantics - what does it mean?

    copy the descendant hierarchy?

    copy the reachability tree? (to avoid dangling references)

    related to [Issue-0038:  Copy by reachability].

Resolution:  Handled in current data model and algebra.

Issue-0062:  Open questions for constructing elements by reference

Date: Sep-25-2000
Raised by: Mary Fernandez et al.

Description:  (1) What is the value of parent() when constructing new elements with children refering to original nodes?

(2) Is an approach to either make copies for all children or provide references to all children, or should we allow for a more flexible combination of copies and references?

Resolution:  Operational semantics specifies that element node constructor creates copies of all its children. Addition of RefNode in [XQuery 1.0 and XPath 2.0 Data Model] supports explicit reference value.

Issue-0063:  Do we need (user defined) higher order functions?

Date: Oct-16-2000
Raised by: Peter Fankhauser

Description:  The current XML-Query-Algebra does not allow functions to be parameters of another function - so called higher order functions. However, most of the Algebra operators are (built-in) higher functions, taking expressions as an argument ("sort", "for", "case" to name a few). Even a fixpoint operator, "fun f(x)=e, fix f(x) in e" (see also [Issue-0008:  Fixed point operator or recursive functions]), would be a built-in higher order function.

Resolution:  The XML Query Algebra will not support user defined higher order functions. It does support a number of built-in higher order functions.

Issue-0064:  Error code handling in Query Algebra

Date: Oct-04-2000
Raised by: Rezaur Rahman

Description:  How do we return an error code from a function defined in current Query algebra. Do we need to create an array (or a structure) to merge the return value and error code to do this. If that is true, it may be inefficient to implement. In order for cleaner and efficient implementation, it may be necessary to allow a function declaration to take a parameter of type "output" and allow it to return an error code as part of the function definition.

Resolution:  One does not need to create a structure to combine return values with error codes, provided each operator or function /either/ returns a value /or/ raises an error. The XML-Query Algebra supports means to raise errors, but does not define standard means to catch errors. Raising errors is accomplished by the expression "error" of type Ø (empty choice). Because Ø | t = t, such runtype errors do not influence static typing. The surface syntax and/or detailed specification of operators on simple types (see [Issue-0056:  Operators on Simple Types]) may choose to differentiate errors into several error-codes.

Issue-0065:  Built-In GroupBy?

Date: Oct-16-2000
Raised by: Peter Fankhauser

Description:  We may revisit the resolution of [Issue-0042:  GroupBy] and reintroduce GroupBy along the lines of sort: "group v in e1 by [e2 {collation}]". One reason for this may be that this allows to use collation for deciding about the equality of strings.

Resolution:  The WG has decided to close this issue, and for the time being not consider GroupBy as a built-in operator. Furthermore, [Issue-0013:  Collations] is ammended to deal with collations for all operators involving a comparison of strings.

Issue-0066:  Shallow or Deep Equality?

Date: Oct-16-2000
Raised by: Peter Fankhauser

Description:  What is the meaning of "=" and "distinct"? Equality of references to nodes or deep equality of data?

Resolution:  [XQuery 1.0 and XPath 2.0 Data Model] defines "=" (value equality) and "==" (identity equality) operators. Description of distinct states that it uses "==".

Issue-0067:  Runtime Casts

Date: Sep-21-2000
Raised by: ???

Description:  In some contexts it may be desirable to cast values at runtime. Such runtime casts lead to an error if a value cannot be cast to a given type.

Resolution:  cast e : t has been introduced as a reducible operator expressed in terms of typeswitch.

Issue-0068:  Document Collections

Date: Oct-16-2000
Raised by: Peter Fankhauser

Description:  Per our requirements document we are chartered to support document collections. The current XML-Query Algebra deals with single documents only. There are a number of subissues:

(a) Do we need a more elaborate notion of node-references? E.g. pair of (URI of root-node, local node-ref)

(b) Does the namespace mechanism suffice to type collections of nodes from different documents? Probably yes.

(c) Provided (a) and (b) can be settled, will the approach taken for [Issue-0049:  Unordered Collections] do the rest?

Resolution:  Document collections are now supported in XQuery 1.0. Input functions have been added, the SequenceType production supports types for document nodes. The XQuery Type system has been extended to support document nodes.

Issue-0069:  Organization of Document

Date: Oct-16-2000
Raised by: Peter Fankhauser

Description:  The current document belongs more to the genre (scientific) paper than to the genre specification. One may consider the following modifications: (a) reorganize intro to give a short overview and then state the purpose (strongly typed, neutral syntax with formal semantics as a basis for possibly multiple syntaxes, etc.) (compared to version Aug-23, this version has already gone a good deal in this direction). (b) Equip various definitions and type rules with id's. (c) Elaborate appendices on mapping XML-Query-Algebra Model vs. XML-Query-Datamodel, XML-Query-Type System vs. XML-Schema-Type System. (d) Maybe add an appendix on use-case-solutions. The problem is of course: Part of this is a lot of work, and we may not achieve all for the first release.

Resolution:  The WG decided to dispose of this issue. The current overall organization of the document is quite adequate, but of course editorial decisions will have to made all the time.

Issue-0070:  Stable vs. Unstable Sort/Distinct

Date: Oct-02-2000
Raised by: Steve Tolkin

Description:  Should sort (and distinct) be stable on ordered collections, i.e. lists, and unstable on unordered collections (see [Issue-0049:  Unordered Collections])?

Resolution:  sort and distinct are stable on ordered collections, and unstable on unordered collections.

Issue-0071:  Alignment with the XML Query Datamodel

Date: Sep-26-2000
Raised by: Mary Fernandez

Description:  Currently, the XML Query Algebra Datamodel does not model PI's and comments.

Resolution:  Addition of operational semantics defines relationship of Algebra to Data Model.

Issue-0072:  Facet value access in Query Algebra

Date: Oct-04-2000
Raised by: Rezaur Rahman

Description:  Each of the date-time data types have facet values as defined by the schema data types draft spec. This problem is general enough to be applied to other simple data types.

The question is : Should we provide access to these facet values on an instance of a particular data types? If so, what type of access? My take is the facets are to be treated like read-only attributes of a data instance and one should have a read access to them.

Issue-0073:  Facets for simple types and their role for typechecking

Date: Oct-16-2000
Raised by: Peter Fankhauser

Description:  XML-Schema introduces a number of constraining facets http://www.w3.org/TR/xmlschema-2/ for simple types (among them: length, pattern, enumeration, ...). We need to figure out whether and how to use these constraining facets for type-checking.

Issue-0074:  Operational semantics for expressions

Date: Nov-16-2000
Raised by: Mary Fernandez

Description:  It is necessary to add an operational semantics that formally defines each operator in the Algebra.

Resolution:  The new document contains a full specification of the dynamic semantics.

Issue-0075:  Overloading user defined functions

Date: Nov-17-2000
Raised by: Don Chamberlain

Description:  User defined functions can not be overloaded in the XML Query Algebra, i.e., a function is exclusively identified by its name, and not by its signature. Should this restriction be relaxed and if so - to which extent?

Resolution:  No overloading in Query 1.0

Issue-0076:  Unordered types

Date: Dec-11-2000
Raised by: Phil Wadler

Description:  Currently unorderedness is represented at type level by {t}, and some (built-in) operators are overloaded such they have different semantics (and potentially different return type) depending on their input type. An alternative is to not represent unorderedness at type level, but rather support unordered for, unordered (unstable) sort, unordered (unstable) distinct.

Resolution:  Removed unordered types from type system. Added support for unordered operator.

Issue-0077:  Interleaved repetition and closure

Date: Dec-12-2000
Raised by: Peter Fankhauser

Description:  Regular Languages are closed w.r.t. to the interleaved product. However, they are not closed w.r.t. to interleaved repetition, which can (e.g) generate the 1 degree Dyck language D[1] = () | a D[1] b | D[1] D[1] = (a,b)^{0,*}, and more generally, any language that coordinates cardinalities of individual members from an alphabeth: E.g. (a ^ b)^ min 0 max * = all strings with equally many a's and b's. These are beyond regular languages. Should we thus try to do without interleaved repetition?

Resolution:  if we use interleaved repetition (which we will because it is in MSL), they will be restricted to prime types.

Issue-0078:  Generation of ambiguous types

Date: Dec-12-2000
Raised by: Jerome Simeon

Description:  Unambiguous content-models in XML 1.0 and XML Schema are not closed w.r.t. union. It appears that the XML Query-Algebra can generate result types which can not be transformed to an unambiguous content-model.

Resolution:  The XQuery type system supports ambiguous types only for intermediate types generated during type inference.

Issue-0079:  Global order between nodes in different documents

Date: Dec-16-2000
Raised by: Algebra Editors

Description:  The global order operator < is defined on nodes in the same document, but not between nodes in different documents.

Resolution:  Resolution follows from the [XPath/XQuery] Data Model. Order between documents is implementation defined but stable.

Issue-0080:  Typing of parent

Date: Dec-16-2000
Raised by: Algebra Editors

Description:  Currently, the parent operator yields an imprecise type : AnyElement min 0 max 1. It might be possible to type parent more precisely, for example, by using the normalized names in MSL, which encode containment of types.

Issue-0081:  Lexical representation of Schema simple types

Date: Jan-17-2001
Raised by: Algebra Editors

Description:  Schema simple types must be defined for the Algebra and [XPath/XQuery].

Resolution:  Algebra will adopt lexical reps supported by [XPath/XQuery].

Issue-0082:  Type and expression operator precedence

Date: Jan-17-2001
Raised by: Algebra Editors

Description:  The precedence of the type expressions is not defined.

Resolution:  Precedence is the same as in XQuery.

Issue-0083:  Expressive power and complexity of typeswitch expression

Date: Jan-17-2001
Raised by: Algebra Editors, Michael Brundage

Description:  When processing an XML document without schema information, i.e., the type of the document is AnyComplexType, then match expressions may be very expensive to evaluate:

  typeswitch x
  case t1 : AnyTree do 1
  case t2 : AnyTree min 0 max 2 do 2
  case t3 : *[*[*[*[* ... [AnyAttribute] ]]]] do 3 
  else ERROR

typeswitch itself is not the issue. The real problem is having very liberal type patterns. We could restrict the kinds of type patterns that we permit.

Resolution:  Typeswitch types are now restricted to sequence types. Named typing will further help in reducing the complexity by allowing type annotation contained in the data model as a means for optimization.

Issue-0084:  Execution model

Date: Jan-17-2001
Raised by: Algebra Editors

Description:  Need prose describing execution model scenarios : interpretor vs. compile/runtime vs. translation into another query language. Explain relationship between static and dynamic semantics.

Resolution:  Section [2.1 Processing model] defines a procesing model which serves as a framework for the Formal Semantics specification.

Issue-0085:  Semantics of Wildcard type

Date: Jan-17-2001
Raised by: Algebra Editors, Michael Brundage

Description:  Cite: wildcard types cannot be implemented. If x!y means any name in x except names in y, what does x!y!z mean? In general, how do ! and | operate (precedence, associativity)? Parentheses are required to force the desired grouping of these two operators. Also, what does x!* mean? (There's an infinite family of such examples.)

Resolution:  The [XPath/XQuery] type systyem now uses only simple wildcard names based on XPath's NameTest production.

Issue-0086:  Syntactic rules

Date: Jan-17-2001
Raised by: Algebra Editors

Description:  Need rules for specifying syntactic correctness of query: symbol spaces; variable def'ns precede uses; list of keywords, etc.

Resolution:  Syntactic rules should be dealt with in [XPath/XQuery] document

Issue-0087:  More examples of Joins

Date: Jan-17-2001
Raised by: Algebra Editors, Michael Brundage

Description:  Cite: no join operator; wants example of many-to-many joins, inner join, left and full outer joins.

Resolution:  The XQuery document gives a number of such examples.

Issue-0088:  Align types with XML Schema : Formal Description.

Date: 02-Apr-2001
Raised by: Mary Fernandez

Description:  Sources of misalignment: [XPath/XQuery] types include comment and processing instruction; [XML Schema : Formal Description] does not. [XPath/XQuery] uses () for empty sequence; MSL uses the epsilon character. [XPath/XQuery] permits the names of attribute and element components to be wildcard expressions. MSL only permits literal names for attributes and elements, but permits stand-alone wildcard expressions. [XPath/XQuery] types call '&' interleaved repetition, but MSL says it means 'all g1 and g2 in either order'. Does MSL mean interleaved repetition?

Resolution:  Closed by the semantics of named typing. The XQuery Type System aligns directly with XML Schema. See Sections 3 and 7 of the Formal Semantics document.

Issue-0089:  Syntax for types in XQuery

Date: 30-Apr-2001
Raised by: Mary Fernandez

Description:  Formalism document gives a particular syntax for type expressions that is not supported in the [XPath/XQuery] surface syntax.

Issue-0090:  Static type-assertion expression

Date: 30-Apr-2001
Raised by: Mary Fernandez

Description:  Formalism document uses a static type-assertion expression that is not supported in the [XPath/XQuery] surface syntax.

Resolution:  Static type assertion is supported in XQuery with the new "assert as" expression.

Issue-0091:  Attribute expression

Date: 30-Apr-2001
Raised by: Mary Fernandez

Description:  [XPath/XQuery] formal semantics has stand-alone attribute constructor/expression ATTRIBUTE QName (Exp) that is not supported in [XPath/XQuery] surface syntax.

Resolution:  Stand-alone attribute construction is supported in XQuery with the new syntax for element and attribute constructors.

Issue-0092:  Error expression

Date: 11-May-2001
Raised by: Jerome Simeon

Description:  [XPath/XQuery] formal semantics has an error expression Error that is not supported in [XPath/XQuery] surface syntax.

Resolution:  Errors are raised by a function "dm:erorr()" instead of a separate expression.

Issue-0093:  Representation of Text Nodes in type system

Date: 11-May-2001
Raised by: Mary Fernandez

Description:  The data model distinguished between text nodes and strings, which are atomic values. Text nodes have identity, parents, and siblings. Strings do not. Text nodes are accessed by the children() accessor; strings and other atomic values are accessed by the typed-value() accessor. The distinction between text nodes and atomic values should exist in type system as well.

Resolution:  Subsumed by new issue [Issue-0105:  Types for nodes in the data model.].

Issue-0094:  Static type errors and warnings

Date: 31-May-2001
Raised by: Don Chamberlin

Description:  Static type errors and warnings are not specified. We need to enumerate in both the [XPath/XQuery] and formal semantics documents what kinds of static type errors and warnings are produced by the type system. See also [Issue-0090:  Static type-assertion expression].

Issue-0095:  Importing Schemas and DTDs into query

Date: 31-May-2001
Raised by: Don Chamberlin

Description:  We do not specify how a Schema or DTD is 'imported' into a query so that its information is available during type checking. Schema and DTDs can either be named explicitly (e.g., by an 'IMPORT SCHEMA' clause in a query) or implicitly, by accessing documents that refer to a Schema or DTD. The mechanism for statically accessing a Schema or DTD is unspecified.

Resolution:  Closed by the semantics of named typing. The new Formal Semantics document contains a complete mapping from XML Schema to the XQuery type system. See Section 7 of the Formal Semantics. Import of DTDs is supported, but should not be described in the Formal Semantics document.

Issue-0096:  Support for schema-less and incompletely validated documents

Date: 31-May-2001
Raised by: Don Chamberlin/Mary Fernandez

Description:  This is related to [Issue-0095:  Importing Schemas and DTDs into query]. We do not specify what is the effect of type checking a query that is applied to a document without a DTD or Schema. In general, a schema-less document has type xs:AnyType and type checking can proceed under that assumption. A related issue is what is the effect of type checking a query that is applied to an incompletely validated document. As above, we can make *no* assumptions about the static type of an incompletely validated document and must assume its static type is xs:AnyType.

Resolution:  XQuery supports schema-less document, and valid documents. It does not support invalid document, I.e., document with a schema for which validation fails. It can support those documents in a well-formed manner.

Issue-0097:  Static type-checking vs. Schema validation

Date: 31-May-2001
Raised by: Mary Fernandez

Description:  Static type checking and schema validation are not equivalent, but we might want to do both in a query. For example, we might want to assert statically that an expression has a particular type and also validate dynamically the value of an expression w.r.t a particular schema.

The differences between static type checking and schema validation must be enumerated clearly (the XSFD people should help us with this).

Resolution:  Closed by the semantics of named typing. XQuery and the XQuery Formals Semantics support both a validate operation and static typing.

Issue-0098:  Implementation of and conformance levels for static type checking

Date: 31-May-2001
Raised by: Don Chamberlin

Description:  This issue is related to [Issue-0059:  Testing Subtyping] Static type checking may be difficult and/or expensive to implement. Some discussion of algorithmic issues of type checking are needed. In addition, we may want to define "conformance levels" for [XPath/XQuery], in which some processors (or some processing modes) are more permissive about types. This would allow [XPath/XQuery] implementations that do not understand all of Schema, and it would allow customers some control over the cost/benefit tradeoff of type checking.

Issue-0099:  Incomplete/inconsistent mapping from to core

Date: 06-June-2001
Raised by: Don Chamberlin

Description:  This mapping is still preliminary and contains inconsistencies. These inconsistencies will be addressed in detail in the next draft of the document.

Resolution:  The Formal Semantics now provides a complete mapping from [XPath/XQuery] to the Core [XPath/XQuery]. Remaining issues with respect to that mapping are indicated separately.

Issue-0100:  Namespace resolution

Date: March-11-2002
Raised by: FS Editors

The way (when? where?) namespace prefixes are resolved is still an open issue.

Issue-0101:  Support for mixed content in the type system

Date: March-11-2002
Raised by: FS Editors

Description:  Support for mixed content in the type system is an open issue. This reopens issue [Issue-0016:  Mixed content]. Dealing with mixed content with interleaving raises complexity issue. See also [Issue-0103:  Complexity of interleaving].

Issue-0102:  Indentation, Whitespace

Date: March-11-2002
Raised by: FS Editors

Description:  Whitespace normalization in [XPath/XQuery] is still an open issue. This reopens issue [Issue-0022:  Indentation, Whitespaces].

Resolution:  New version now describes the semantics of element constructors and whitespace handling.

Issue-0103:  Complexity of interleaving

Date: March-11-2002
Raised by: FS Editors

Description:  The current type system allows interleaving is allowed on arbitrary types. Interleaving is an expensive operation and it is not clear how to define subtyping for it. Should we restrict use of interleaving on (optional) atomic types ? Should this restriction reflects the one in XML schema ? Related to [Issue-0077:  Interleaved repetition and closure].

Issue-0104:  Support for named typing

Date: March-11-2002
Raised by: FS Editors

Description:  XML Schema is based on named typing, while the [XPath/XQuery] type system is based on strucural typing. Directly related issues are [Issue-0019:  Support derived types] and [Issue-0018:  Align algebra types with schema]. Other impacted issues are [Issue-0020:  Structural vs. name equivalence], [Issue-0072:  Facet value access in Query Algebra], [Issue-0073:  Facets for simple types and their role for typechecking], [Issue-0088:  Align types with XML Schema : Formal Description.], [Issue-0095:  Importing Schemas and DTDs into query], [Issue-0097:  Static type-checking vs. Schema validation], [Issue-0098:  Implementation of and conformance levels for static type checking], [Issue-0111:  Semantics of instance of ... only].

Resolution:  Closed by the semantics of named typing. The Formal Semantics now support both named and structural typing. See Sections 3 and 7 of the Formal Semantics document.

Issue-0105:  Types for nodes in the data model.

Date: March-11-2002
Raised by: FS Editors

Description:  The [XPath/XQuery] type system only supports element and attribute nodes. It needs to support other kinds of nodes from the [XPath/XQuery] datamodel, notably: text nodes and document nodes. Should it also include support for PI nodes, comment nodes and namespace nodes?

The data model distinguishes between text nodes and strings, which are atomic values. Text nodes have identity, parents, and siblings. Strings do not. Text nodes are accessed by the children() accessor; strings and other atomic values are accessed by the typed-value() accessor. The distinction between text nodes and atomic values should exist in type system as well.

Resolution:  The new type system supports document and text nodes. Support for other kinds of nodes is discussed in [Issue-0143:  Support for PI, comment and namespace nodes]

Issue-0106:  Constraint on attribute and element content models

Date: March-11-2002
Raised by: Jerome

Description:  The [XPath/XQuery] type system allows more content model than what XML Schema allows. For instance, the current type grammar allows the following types:

   element d { (attribute a | element b, attribute c)* }
   attribute a { element b }

Section [3 The XQuery type system] indicates corresponding constraints on the [XPath/XQuery] type system to avoid that problem. The status of these constraints is unclear. When are they enforced and checked?

Issue-0107:  Semantics of data()

Date: March-11-2002
Raised by: FS Editors

Description:  What is the semantics of data() applied to anything else than an element or attribute node ?

Issue-0108:  Principal node types in XPath

Date: March-11-2002
Raised by: Michael Kay

Description:  There is a known bug in the formal semantics which does not deal properly with principal node types. This bug should be resolved based on some semantics previously proposed by Phil Wadler.

Resolution:  The bug in the semantics of XPath has been fixed in the current version of the document. See [5.2.1 Steps].

Issue-0109:  Semantics of order by

Date: March-11-2002
Raised by: Jerome

Description:  The precise semantics of order by is still open issue.

Issue-0110:  Semantics of element and attribute constructors

Date: March-11-2002
Raised by: Jerome

Description:  The precise semantics of element constructors is still an open issue.

Issue-0111:  Semantics of instance of ... only

Date: March-11-2002
Raised by: Mary Fernandez

Description:  The "instance of" expression allows an optional "only" modifier. The use case for such a modifier is based on named typing, while the XQuery semantics is currently based on structural typing. It is not clear what the semantics of the "only" modifier under structural typing should be and how it can be supported.

Resolution:  XQuery does not support only anymore.

Issue-0112:  Typing for the typeswitch default clause

Date: March-11-2002
Raised by: Jerome

Description:  There is an asymetry in the typing for the default clause in typeswitch vs. the other case clauses. This results in a less precise type when the default clause can be applied.

It would be nicer to be able to have the type be more precise, like for the other case clauses.

The technical problem is the need for some form of negation. I think one could define a "non-common-primes" function that would do the trick, but I leave that as open for now until further review of the new typeswitch section is made.

Issue-0113:  Incomplete specification of type conversions

Date: March-11-2002
Raised by: Mary Fernandez

Description:  Not all the fallback conversion rules are specified yet in section [4.4.3 Type Conversions]. All the remaining rules in the fallback conversions table must be specified.

Issue-0114:  Dynamic context for current date and time

Date: March-11-2002
Raised by: Jerome

Description:  The following components dynamic contexts have no formal representation yet: current date and time.

Related question: where are these context components used?

Issue-0115:  What is in the default context?

Date: March-11-2002
Raised by: Jerome

Description:  What do the default namespace and type environments contain? I believe at least the default namespace environment should contain the "xs", "fn" and "op" prefixes, as well as the default namespaces bound to the empty namespace. Should the default type environment contain wildcard types?

Issue-0116:  Serialization

Date: March-11-2002
Raised by: Jerome

Description:  Serialization of data model instances, and XQuery results is still an open issue.

Issue-0117:  Data model constructor for error values

Date: March-11-2002
Raised by: Jerome

Description:  The [XPath/XQuery] data model supports an error value, but there is no constructor for it. Currently the formal semantics is using the notation dm:error() to create an error value. Should there be some function(s) in the [XQuery 1.0 and XPath 2.0 Functions and Operators] document to create error values?

Issue-0118:  Data model syntax and literal values

Date: March-11-2002
Raised by: Phil Wadler

Description:  Phil suggests the data model should support primitive literals in their lexical form, in which case no explicit dynamic semantic rule would be necessary.

More generally, should the data model support a constructor syntax?

Issue-0119:  Semantics of op:to

Date: March-11-2002
Raised by: Mary Fernandez

Description:  The binary operator "to" is not defined on empty sequences. The [XQuery 1.0 and XPath 2.0 Functions and Operators] document says operands are decimals, while the XQuery document says they are integers. What happens when Expr1 > Expr2?

Issue-0120:  Sequence operations: value vs. node identity

Date: March-11-2002
Raised by: Mary Fernandez

Description:  The [XQuery 1.0 and XPath 2.0 Functions and Operators] document provides only one function for union (intersect, etc.) of sequences of nodes and values. The semantics is very different for node only and value only sequences. The semantics is undefined for heterogeneous sequences. Should we have two union (intersect, etc.) functions, one for nodes, and one for values?

Issue-0121:  Casting functions

Date: March-11-2002
Raised by: Jerome

Description:  The [XQuery 1.0 and XPath 2.0 Functions and Operators] document does not provide any function for casting, just a table and casting rules. Wouldn't it be preferable to either have an explicit function to normalize to? This relates to Issue 17 in the [XQuery 1.0 and XPath 2.0 Functions and Operators] document.

Issue-0122:  Overloaded functions

Date: March-11-2002
Raised by: Denise Draper

Description:  Some [XQuery 1.0 and XPath 2.0 Functions and Operators] functions are overloaded. How to deal with overloaded built-in functions in the Formal Semantics is still an open issue.

Resolution:  overloaded (built-in) functions have distinct entries in the static and dynamic function environment.

Issue-0123:  Semantics of /

Date: March-11-2002
Raised by: FS Editors

Description:  Some of the semantics of the root expression / is still an open issue. For instance, what should be the semantics of '/' in case of a document fragment (I.e., created using XQuery element constructor).

Issue-0124:  Binding position in FLWR expressions

Date: March-11-2002
Raised by: FS Editors

Description:  The only way to bind position() is through implicit operations. It would be useful and cleaner to also have a way to bind position in a sequence explicitely. The FS editors proposed several syntax for such an operation, one of these syntaxes look like "for $v at $i in E1 return E2" which modifies the for expression to bind a variable "$i" to the position in sequence "E1" explicitely.

Resolution:  FLWR expressions now support an 'at $i' optional variable binding to the position within the input sequence. This is used to describe the semantics of position() in path expressions.

Issue-0125:  Operations on node only in XPath

Date: March-11-2002
Raised by: FS Editors

Description:  Generally steps may operate on nodes and values alike; the axis rules only can operate on nodes (NodeValue). Is it a dynamic error to apply an axis rule on a value?

More generally, the XQuery document states that XPath operates on nodes only. Where that restriction should be applied is an open issue.

Resolution:  The November 4th working draft fixes XPath normalization rules so that imposing sorting by document order is done correctly. Sorting by document order fails when the sequence contains items which are note nodes.

Issue-0126:  Semantics of effective boolean value

Date: March-11-2002
Raised by: FS Editors

Description:  Some of the semantics of effective boolean value is still an open issue.

Resolution:  EBV is aligned with the fn:boolean() function.

Issue-0127:  SequenceType limitations

Date: March-11-2002
Raised by: FS Editors

Description:  Should the SequenceType production allow the following: fs:atomic, fs:numeric, fs:UnknownSimpleType ?

The formal semantics makes use of several built-in types which are not in XML Schema: fs:numeric, fs:atomic, and fs:UnknownSimpleType. These types are necessary for the specification of some of XPath type conversion rules, and will be accepted without raising an error.

Issue-0128:  Casting based on the lexical form

Date: March-11-2002
Raised by: Mary Fernandez

Description:  The XQuery/XPath spec says : "If an operand is an untyped simple value (...), it is cast to the type suggested by its lexical form." It is not clear how to define the semantics for this.

Issue-0129:  Static typing of union

Date: March-11-2002
Raised by: Michael Rys

Description:  What should be the semantics of arithmetics expressions over unions. Right now, it would raise a dynamic error. Do we want to raise a static error?

Should operators and functions consistenly with respect to typing?

With the current semantics in Section 4.5 expr1 + expr2 raises a static type error if (e.g.) expr1 has type string and expr2 has type integer. It raises only a dynamic error, if expr1 has type (string | integer) and expr2 has type integer, and expr1 actually evaluates to a string. An alternative would be that this raises also a static error, because it cannot be guarantueed to succeed on all instances.

Issue-0130:  When to process the query prolog

Date: March-11-2002
Raised by: Jerome

Description:  The query prolog needs to be processed before the normalization phase. This is not reflected yet in the processing model.

Issue-0131:  Boolean node test and sequences

Date: March-11-2002
Raised by: Michael Rys

Description:  The current semantics for boolean node tests makes it "true if the expression is a sequence that contains at least one node and error if the sequence contains no node". This is inefficient to implement. Some alternative semantics have been proposed.

Resolution:  Boolean value of sequence now independ from whether it is nodes-only.

Issue-0132:  Typing for descendant

Date: March-11-2002
Raised by: Peter Fankhauser

Description:  The current static typing for descendant is still under review and the inferences rules in that version are probably containing bugs.

Issue-0133:  Should to also be described in the formal semantics?

Date: March-11-2002
Raised by: Michael Kay

Description:  The current semantics of the op operator is using the op:to function from the [XQuery 1.0 and XPath 2.0 Functions and Operators] document. Should it be defined formally?

Mike Kay suggests the following definition: [A to B] => if A=B then (A) else (A, A+1 to B)

Issue-0134:  Should we define for with head and tail?

Date: March-11-2002
Raised by: Michael Kay

Description:  Mike Kay proposes to use the following recursion to define the dynamic semantics of for:

[for $x in () return E2] => ()
[for $x in SEQ return E2] =>
(let $x := head(SEQ) return E2, for $x in tail(SEQ) return E2)

Unfortunately head and tail are not define in [XQuery 1.0 and XPath 2.0 Functions and Operators] right now.

Issue-0135:  Semantics of special functions

Date: March-11-2002
Raised by: Michael Kay

Description:  The current semantics does not completely cover built-in functions. Some functions used in the Formal semantics, or some functions from the [XQuery 1.0 and XPath 2.0 Functions and Operators] document need additional semantics specification.

Issue-0136:  Non-determinism in the semantics

Date: May-01-2002
Raised by: Mary Fernandez

Description:  Some operations, such as logical operations and quantified operations are not deterministics ("early-out" semantics allowing not to evaluate all of the expressions). The formal semantics cannot capture the non-determinism in those operations.

Issue-0137:  Typing of input functions

Date: May-01-2002
Raised by: Jerome Simeon

Description:  Static typing for the input functions input, collection, and document is still undefined.

Issue-0138:  Semantics of Schema Context

Date: May-01-2002
Raised by: Jerome Simeon

Description:  The semantics of Schema Context types in the SequenceType production is still an open issue.

Issue-0139:  Type equivalence rules

Date: May-08-2002
Raised by: Michael Rys

Description:  Should we add back equivalence rules for types (e.g., T1** == T1* or (T1 | T1) == T1). They are useful in practical implementations (e.g., to print an infered type or reduce complexity of infered types), and could be added in an appendix.

Issue-0140:  Dependency in normalization and function resolution

Date: May-08-2002
Raised by: Michael Rys

Description:  The normalization of functions calls depends on the function signature. But you cannot gather the function signature for built-in functions without knowing the type of the parameters.

Resolution:  the dependencies on the static/dynamic environment of the normalization/analysis/evaluation phases is now in order (even if not always explicit).

Issue-0141:  Treatment of nillability and xsi:nil

Date: May-08-2002
Raised by: Michael Rys

Description:  Nillability on an element declaration indicates that content of the corresponding element can be empty. The current data model preserves the xsi:nil attribute and this is used in the semantics at the type level. An alternative design would be to remove the xsi:nil attribute and add a 'nillable' marker in the schema component in the data model. This might be helping when we perform updates.

Issue-0142:  Treatment of xsi:type in validation

Date: May-15-2002
Raised by: XQuery Editors

Description:  The treatment of xsi:type in the formal semantics differs from the one specified in the XQuery and XPath documents. The XQuery and XPath documents indicate that validation is performed by serializing the data model value with newly created xsi:type attributes, then removing those xsi:type attributes after validation. The semantics of 'erases to' as described in the formal semantics document is not creating any xsi:type attributes. The semantics of 'annotate as' as described in the formal semantics document is not removing any xsi:type attributes.

Resolution:  [XPath/XQuery] document and formal semantics document now treat xsi:type in the same way, taking them into account during validation, but never adding or removing those attributes.

Issue-0143:  Support for PI, comment and namespace nodes

Date: May-15-2002
Raised by: FS Editors

Description:  The [XPath/XQuery] type system does not currently support PI nodes, comment nodes and namespace nodes.

Issue-0144:  Representation of text nodes in formal values

Date: May-15-2002
Raised by: Jonathan Robie

Description:  Formal Values described in section [3.1 Values] represents either text nodes for well-formed documents or values for validated documents. Do we need to support a dual representation with both text nodes and values in the formal semantics?

Issue-0145:  Static typing of path expressions in the presence of derivation by extension

Date: May-15-2002
Raised by: Jerome Simeon

Description:  The current static type analysis rules for Step expressions is broken in the presence of derivation by extension. This bug is impacting section [5.2.1 Steps].

Issue-0146:  Support for substitution groups

Date: May-15-2002
Raised by: Jerome Simeon

Description:  The formal semantics document gives a semantics of substitution groups. This is not aligned with the XQuery document. Support for substitution group in XQuery is still an open issue.

Note that this issue is related to the typing of substitution groups, and should be distinguished from the question about whether we need expressions in the language that operate on substitution groups.

Resolution:  Type matching in XQuery is aligned with the formal semantics and takes substitution groups into account.

Issue-0147:  What should be the type annotation in the data model for anonymous types?

Date: May-15-2002
Raised by: Jerome Simeon

Description:  It is not clear what should be the type annotation in the data model for anonymous types. The mapping from the PSVI to the data model and the formal semantics document need to be aligned.

Resolution:  XQuery does not support only anymore.

Issue-0148:  Validation of an empty string against a string list

Date: May-15-2002
Raised by: Jerome Simeon

Description:  The formal semantics assumes that the result of validating an element with empty content or with an empty text node against a list of strings is the empty sequence, not the empty string. Is that consistent with XML Schema?

Issue-0149:  Derivation by extension in XQuery

Date: May-15-2002
Raised by: Phil Wadler

Description:  If type u is derived from type t by extension, then the formal semantics document specifies that type u may appear wherever type t is expected. It is not clear what the XQuery document says on this point.

Issue-0150:  May the content of a text node be the empty string?

Date: May-15-2002
Raised by: Phil Wadler

Description:  May the content of a text node be the empty string? None of the formal semantics, the datamodel, or the XQuery document addresses this point.

Issue-0151:  Should type annotations be optional?

Date: May-15-2002
Raised by: Phil Wadler

Description:  The formal semantics and the data model both state that the type annotation is required, while the XQuery document says that it is optional.

Resolution:  Type annotations are mandatory under pure named typing.

Issue-0152:  What is the type of the input functions?

Date: May-30-2002
Raised by: FS Editors

Description:  What are the (static) types for the input functions: document(), collection(), and input()?

Issue-0153:  Support for lax and strict wildcards

Date: May-30-2002
Raised by: FS Editors

Description:  The Formal Semantics does not currently model lax and strict wildcards. The mapping in Section 7, only describes how XML Schema wilcards with the 'skip validation' semantics are imported into the XQuery Type System.

Issue-0154:  Semantics of =>

Date: May-30-2002
Raised by: Jerome Simeon

Description:  The Formal Semantics of the => operator is not defined.

Resolution:  The => operator has been removed from the language.

Issue-0155:  Common primes for incomparable types

Date: June-06-2002
Raised by: Jerome Simeon

Description:  The common-prime auxiliary type function does not deal with "incomparable" types, (i.e., types for which there is a non empty intersection, but subtyping does not hold -- e.g., element a | element b vs. element b | element c). One way to resolves that issue would be to re-introduce a limited form of intersection (i.e., returning true if the intersection is not empty instead of full-fledge intersection) and use it within the definition of common-prime.

Resolution:  New version of common prime based on pure named typing is simpler and works for all kinds of items.

Issue-0156:  Casting and validation

Date: Jun-06-2002
Raised by: Jerome Simeon

Description:  Validation from text to simple type performs an operation similar to casting. Should validation of simple type values and 'cast as' in [XPath/XQuery] be aligned?

Issue-0157:  Support for wildcard namespaces

Date: Jun-06-2002
Raised by: Jerome Simeon

Description:  The Formal Semantics does not currently model wildcard namespaces.

Issue-0158:  Support for XML Schema groups

Date: Jun-06-2002
Raised by: Jerome Simeon

Description:  How to support XML Schema groups during the schema import phase is not clear. If the mapping is based on the XML Schema syntax, then it should be handled durin the mapping phase. Should we have support for XML Schema groups in the XQuery type system?

Issue-0159:  Element and attribute declarations in the static context

Date: Jun-06-2002
Raised by: Jerome Simeon

Description:  The [XPath/XQuery] static context only contains type definitions, but no global element and attribute declarations. Element and attribute declarations are necessary to give the semantics of SequenceTypes.

Issue-0160:  Collations in the static environment

Date: Jun-06-2002
Raised by: Jerome Simeon

Description:  The Formal Semantics does not represent collations in the static environment. Should it?

Issue-0161:  Type promotion in Atomization

Date: Jun-06-2002
Raised by: Don Chamberlin

Description:  Should the normalization rules for atomization also perform type promotion?

Resolution:  Type promotion is done in function calls.

Issue-0162:  How to describe the semantics of built-in functions

Date: Jun-06-2002
Raised by: Don Chamberlin

Description:  The semantics of function calls assumes the function environment returns an [XPath/XQuery] expression which describes the function body. This only works for user-defined functions, but not for external functions or built-in functions.

Resolution:  built-in functions given special rule that refers to "application" which in turn refers to FO, datamodel, etc.

Issue-0163:  Normalization of XPath predicates

Date: Jun-06-2002
Raised by: Don Chamberlin

Description:  The semantics of XPath predicates relies on whether they are applied on forward or reverse axis. The semantics of predicates applied on arbitrary expressions is not correctly specified.

Resolution:  The November 4th working draft fixes XPath normalization rules for XPath predicates on arbitrary expressions. The semantics in that case is as for forward axis.

Issue-0164:  Coalescing text nodes in element constructors

Date: Jun-06-2002
Raised by: Don Chamberlin

Description:  The semantics does not model how text nodes are coalesced in element or constructors. Whether it should be described or left out for the data model is still an open issue. Impact on this operation on the static semantics is still an open issue.

Resolution:  The data model element constructor coalesces text nodes.

Issue-0165:  Namespaces in element constructors

Date: Jun-06-2002
Raised by: Denise Draper

Description:  We do not supply either namespaces or schema-components to the constructor. We cannot do these things because of the bottom-up nature of element construction: we do not, in general, know either the namespaces in scope or the validation-associated schema type until this element has been "seated" in some containing element (and so on recursively).

Issue-0166:  Static typing for validate

Date: Jun-06-2002
Raised by: Jerome Simeon

Description:  Although validate should always return a typed value, there is no way to do static analysis for it, since the type against which it is validated cannot be known at static type (it depends on the result of evaluation for the input expression).

Issue-0167:  Is validate working on sequences?

Date: Jun-06-2002
Raised by: Jerome Simeon

Description:  Should validate work on sequences of nodes, or only on a single node?

Issue-0168:  Sorting by document order

Date: Jun-06-2002
Raised by: Jerome Simeon

Description:  There is no way in [XPath/XQuery] to express sorting by document order as a core expression. Since order by is doing atomization, there is no way it can be used to express sorting by document order.

Issue-0169:  Conformance Levels

Date: Jun-06-2002
Raised by: Jerome Simeon

Description:  [XPath/XQuery] supports several conformance levels. Whether the formal semantics need to distinguish those conformance levels is an open issue. If yes, how to distinguish those conformance levels in the formal semantics is an open issue.

Issue-0170:  Imprecise static type of constructed elements

Date: Jul-26-2002
Raised by: Mary Fernandez

Description:  Implementation of Alternative 1 means that the static type for constructed elements and attributes is very imprecise. E.g., the type of {(1,2,3)} is element a { xs: anyType }. See remark by Denise in section on element constructors for possible fix.

Issue-0171:  Raising errors

Date: Jul-26-2002
Raised by: Mary Fernandez

Description:  The semantics of raising errors in [XPath/XQuery] is not formally specified.

Issue-0172:  Element constructors aligned with XSLT

Date: Jul-26-2002
Raised by: Jerome Simeon

Description:  Should the semantics of element constructors be aligned with XSLT?.

Issue-0173:  Typeswitch and type substitutability

Date: Jul-26-2002
Raised by: XSL Working Group

Description:  It seems that some examples of typeswitch with xs:anySimpleType might break type substitutability.

Issue-0174:  Semantics of 'element foo of type T'

Date: Jul-30-2002
Raised by: Jerome Simeon

Description:  When using the form 'element foo of type T', should 'foo' be a globally declared element in the in-scope schema or not? Should there be constraints on which type T is allowed? The language document assumes foo is globally declared and T is a restriction of the type of foo. The formal semantics does not make that assumption.

Resolution:  Sequence type matching in the language book is aligned with the formal semantics in the case in the case of 'element foo of type T'. 'T' must be a globally defined name. 'foo' is just considered as a local element name.

Issue-0175:  Static typing for atomization, effective boolean values, and function arguments.

Date: Jul-30-2002
Raised by: Jerome Simeon

Description:  Currently, normalization rules for atomization, effective boolean values, and function arguments are not type safe. They cannot raise a static errors, but can only raise dynamic errors. This makes the static semantics much less usable.

Resolution:  atomization and function parameters are now strictly typed, EBV uses the all-accepting fn:boolean function.

Issue-0176:  Type of document node

Date: Oct-30-2002
Raised by: Jerome Simeon

Description:  What should the type of a document node be? Should a document node be described by a type name?

Issue-0177:  Coercion between untyped and atomic values

Date: Oct-30-2002
Raised by: Jerome Simeon

Description:  Function calls, arithmetics expressions, etc. should cast untyped data to values. This is not currently formally specified.

Issue-0178:  Semantics of XPath 1.0 compatibility

Date: Oct-30-2002
Raised by: Jerome Simeon

Description:  The semantics is not specified in the case the XPath 1.0 compatibility flag is on.

Issue-0179:  Primitive function applications

Date: Oct-30-2002
Raised by: Jerome Simeon

Description:  The semantics of primitive function applications must be defined precisely.

D.3 Alphabetic list of issues

D.3.1 Open Issues

Number: 64

[Issue-0156:  Casting and validation]
[Issue-0128:  Casting based on the lexical form]
[Issue-0121:  Casting functions]
[Issue-0177:  Coercion between untyped and atomic values]
[Issue-0160:  Collations in the static environment]
[Issue-0103:  Complexity of interleaving]
[Issue-0169:  Conformance Levels]
[Issue-0106:  Constraint on attribute and element content models]
[Issue-0117:  Data model constructor for error values]
[Issue-0118:  Data model syntax and literal values]
[Issue-0149:  Derivation by extension in XQuery]
[Issue-0114:  Dynamic context for current date and time]
[Issue-0159:  Element and attribute declarations in the static context]
[Issue-0172:  Element constructors aligned with XSLT]
[Issue-0073:  Facets for simple types and their role for typechecking]
[Issue-0072:  Facet value access in Query Algebra]
[Issue-0098:  Implementation of and conformance levels for static type checking]
[Issue-0170:  Imprecise static type of constructed elements]
[Issue-0113:  Incomplete specification of type conversions]
[Issue-0167:  Is validate working on sequences?]
[Issue-0150:  May the content of a text node be the empty string?]
[Issue-0100:  Namespace resolution]
[Issue-0165:  Namespaces in element constructors]
[Issue-0136:  Non-determinism in the semantics]
[Issue-0179:  Primitive function applications]
[Issue-0171:  Raising errors]
[Issue-0144:  Representation of text nodes in formal values]
[Issue-0123:  Semantics of /]
[Issue-0107:  Semantics of data()]
[Issue-0110:  Semantics of element and attribute constructors]
[Issue-0119:  Semantics of op:to]
[Issue-0109:  Semantics of order by]
[Issue-0138:  Semantics of Schema Context]
[Issue-0135:  Semantics of special functions]
[Issue-0178:  Semantics of XPath 1.0 compatibility]
[Issue-0120:  Sequence operations: value vs. node identity]
[Issue-0127:  SequenceType limitations]
[Issue-0116:  Serialization]
[Issue-0133:  Should to also be described in the formal semantics?]
[Issue-0134:  Should we define for with head and tail?]
[Issue-0168:  Sorting by document order]
[Issue-0094:  Static type errors and warnings]
[Issue-0166:  Static typing for validate]
[Issue-0145:  Static typing of path expressions in the presence of derivation by extension]
[Issue-0129:  Static typing of union]
[Issue-0153:  Support for lax and strict wildcards]
[Issue-0101:  Support for mixed content in the type system]
[Issue-0143:  Support for PI, comment and namespace nodes]
[Issue-0157:  Support for wildcard namespaces]
[Issue-0158:  Support for XML Schema groups]
[Issue-0089:  Syntax for types in XQuery]
[Issue-0141:  Treatment of nillability and xsi:nil]
[Issue-0139:  Type equivalence rules]
[Issue-0176:  Type of document node]
[Issue-0173:  Typeswitch and type substitutability]
[Issue-0132:  Typing for descendant]
[Issue-0112:  Typing for the typeswitch default clause]
[Issue-0137:  Typing of input functions]
[Issue-0080:  Typing of parent]
[Issue-0148:  Validation of an empty string against a string list]
[Issue-0115:  What is in the default context?]
[Issue-0152:  What is the type of the input functions?]
[Issue-0130:  When to process the query prolog]
[Issue-0011:  XPath tumbler syntax instead of index?]

D.3.2 Resolved (or redundant) Issues

Number: 115

[Issue-0015:  3-valued logic to support NULLs]
[Issue-0018:  Align algebra types with schema]
[Issue-0071:  Alignment with the XML Query Datamodel]
[Issue-0088:  Align types with XML Schema : Formal Description.]
[Issue-0091:  Attribute expression]
[Issue-0001:  Attributes]
[Issue-0047:  Attributes]
[Issue-0030:  Automatic type coercion]
[Issue-0052:  Axes of XPath]
[Issue-0124:  Binding position in FLWR expressions]
[Issue-0131:  Boolean node test and sequences]
[Issue-0065:  Built-In GroupBy?]
[Issue-0027:  Case syntax]
[Issue-0040:  Case Syntax]
[Issue-0023:  Catch exceptions and process in algebra?]
[Issue-0164:  Coalescing text nodes in element constructors]
[Issue-0013:  Collations]
[Issue-0155:  Common primes for incomparable types]
[Issue-0010:  Construct values by copy]
[Issue-0038:  Copy by reachability]
[Issue-0037:  Copy vs identity semantics]
[Issue-0140:  Dependency in normalization and function resolution]
[Issue-0039:  Dereferencing semantics]
[Issue-0068:  Document Collections]
[Issue-0003:  Document Order]
[Issue-0063:  Do we need (user defined) higher order functions?]
[Issue-0058:  Downward Navigation only?]
[Issue-0005:  Element identity]
[Issue-0064:  Error code handling in Query Algebra]
[Issue-0092:  Error expression]
[Issue-0035:  Exception handling]
[Issue-0084:  Execution model]
[Issue-0048:  Explicit Type Declarations]
[Issue-0083:  Expressive power and complexity of typeswitch expression]
[Issue-0009:  Externally defined functions]
[Issue-0008:  Fixed point operator or recursive functions]
[Issue-0046:  FOR Syntax]
[Issue-0032:  Full regular path expressions]
[Issue-0028:  Fusion]
[Issue-0034:  Fusion]
[Issue-0078:  Generation of ambiguous types ]
[Issue-0045:  Global Order]
[Issue-0036:  Global-order based operators]
[Issue-0079:  Global order between nodes in different documents]
[Issue-0054:  Global vs. local complex types]
[Issue-0053:  Global vs. local elements]
[Issue-0042:  GroupBy]
[Issue-0012:  GroupBy - needs second order functions?]
[Issue-0162:  How to describe the semantics of built-in functions]
[Issue-0095:  Importing Schemas and DTDs into query]
[Issue-0099:  Incomplete/inconsistent mapping from to core]
[Issue-0102:  Indentation, Whitespace]
[Issue-0022:  Indentation, Whitespaces]
[Issue-0077:  Interleaved repetition and closure]
[Issue-0060:  Internationalization aspects for strings]
[Issue-0044:  Keys and IDREF]
[Issue-0081:  Lexical representation of Schema simple types]
[Issue-0033:  Metadata Queries]
[Issue-0016:  Mixed content]
[Issue-0061:  Model for References]
[Issue-0087:  More examples of Joins]
[Issue-0057:  More precise type system; choice in path]
[Issue-0002:  Namespaces]
[Issue-0163:  Normalization of XPath predicates]
[Issue-0062:  Open questions for constructing elements by reference]
[Issue-0074:  Operational semantics for expressions]
[Issue-0125:  Operations on node only in XPath]
[Issue-0056:  Operators on Simple Types]
[Issue-0069:  Organization of Document]
[Issue-0122:  Overloaded functions]
[Issue-0075:  Overloading user defined functions]
[Issue-0014:  Polymorphic types]
[Issue-0108:  Principal node types in XPath]
[Issue-0026:  Project - one tag only]
[Issue-0051:  Project redundant?]
[Issue-0050:  Recursive Descent for XPath]
[Issue-0043:  Recursive Descent for XPath]
[Issue-0031:  Recursive functions]
[Issue-0007:  References: IDREFS, Keyrefs, Joins]
[Issue-0004:  References vs containment]
[Issue-0093:  Representation of Text Nodes in type system]
[Issue-0067:  Runtime Casts]
[Issue-0174:  Semantics of 'element foo of type T']
[Issue-0154:  Semantics of =>]
[Issue-0126:  Semantics of effective boolean value]
[Issue-0111:  Semantics of instance of ... only]
[Issue-0085:  Semantics of Wildcard type]
[Issue-0066:  Shallow or Deep Equality?]
[Issue-0151:  Should type annotations be optional?]
[Issue-0041:  Sorting]
[Issue-0006:  Source and join syntax instead of "for"]
[Issue-0070:  Stable vs. Unstable Sort/Distinct]
[Issue-0090:  Static type-assertion expression]
[Issue-0097:  Static type-checking vs. Schema validation]
[Issue-0175:  Static typing for atomization, effective boolean values, and function arguments.]
[Issue-0020:  Structural vs. name equivalence]
[Issue-0019:  Support derived types]
[Issue-0104:  Support for named typing]
[Issue-0096:  Support for schema-less and incompletely validated documents]
[Issue-0146:  Support for substitution groups]
[Issue-0086:  Syntactic rules]
[Issue-0021:  Syntax]
[Issue-0059:  Testing Subtyping]
[Issue-0025:  Treatment of empty results at type level]
[Issue-0142:  Treatment of xsi:type in validation]
[Issue-0082:  Type and expression operator precedence]
[Issue-0161:  Type promotion in Atomization]
[Issue-0105:  Types for nodes in the data model.]
[Issue-0055:  Types with non-wellformed instances]
[Issue-0049:  Unordered Collections]
[Issue-0017:  Unordered content]
[Issue-0076:  Unordered types]
[Issue-0024:  Value for empty sequences]
[Issue-0029:  Views]
[Issue-0147:  What should be the type annotation in the data model for anonymous types?]