W3C

XQuery 1.0: An XML Query Language

W3C Working Draft 16 August 2002

This version:
http://www.w3.org/TR/2002/WD-xquery-20020816/
Latest version:
http://www.w3.org/TR/xquery/
Previous versions:
http://www.w3.org/TR/2002/WD-xquery-20020430/
http://www.w3.org/TR/2001/WD-xquery-20011220/
http://www.w3.org/TR/2001/WD-xquery-20010607/
Editors:
Scott Boag (XSL WG), IBM Research <scott_boag@us.ibm.com>
Don Chamberlin (XML Query WG), IBM Almaden Research Center <chamberlin@almaden.ibm.com>
Mary F. Fernandez (XML Query WG), AT&T Labs <mff@research.att.com>
Daniela Florescu (XML Query WG), XQRL <dana@xqrl.com>
Jonathan Robie (XML Query WG), DataDirect Technologies <jonathan.robie@datadirect-technologies.com>
Jérôme Siméon (XML Query WG), Bell Labs, Lucent Technologies <simeon@research.bell-labs.com>

Abstract

XML is a versatile markup language, capable of labeling the information content of diverse data sources including structured and semi-structured documents, relational databases, and object repositories. A query language that uses the structure of XML intelligently can express queries across all these kinds of data, whether physically stored in XML or viewed as XML via middleware. This specification describes a query language called XQuery, which is designed to be broadly applicable across many types of XML data sources.

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 made obsolete 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/.

Much of this document is the result of joint work by the XML Query and XSL Working Groups, which are jointly responsible for XPath 2.0, a language derived from both XPath 1.0 and XQuery. The XPath 2.0 and XQuery 1.0 Working Drafts are generated from a common source. These languages are closely related, sharing much of the same expression syntax and semantics, and much of the text found in the two Working Drafts is identical.

This version of the document contains new details about error handling and conformance. It contains a new grammar in which the precedence of operators is explicitly represented. It introduces two new operators (unordered and idiv), and deletes four operators (assert, precedes, follows, and =>). It introduces two new declarations into the Query Prolog, called xmlspace and default collation. It also describes changes to the detailed semantics of cast expressions, element constructors, and other operators, as summarized in F Revision Log.

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.

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 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 Basics
    2.1 Expression Context
        2.1.1 Static Context
        2.1.2 Evaluation Context
    2.2 Input Functions
    2.3 Expression Processing
        2.3.1 Document Order
        2.3.2 Typed Value and String Value
    2.4 Types
        2.4.1 Type Checking
        2.4.2 SequenceType
        2.4.3 Type Conversions
            2.4.3.1 Atomization
            2.4.3.2 Effective Boolean Value
    2.5 Errors and Conformance
        2.5.1 Errors
        2.5.2 Conformance
            2.5.2.1 Basic XQuery
            2.5.2.2 Schema Import Feature
            2.5.2.3 Static Typing Feature
        2.5.3 Handling Dynamic Errors
3 Expressions
    3.1 Primary Expressions
        3.1.1 Literals
        3.1.2 Variables
        3.1.3 Parenthesized Expressions
        3.1.4 Function Calls
        3.1.5 Comments
    3.2 Path Expressions
        3.2.1 Steps
            3.2.1.1 Axes
            3.2.1.2 Node Tests
        3.2.2 Predicates
        3.2.3 Unabbreviated Syntax
        3.2.4 Abbreviated Syntax
    3.3 Sequence Expressions
        3.3.1 Constructing Sequences
        3.3.2 Combining Sequences
    3.4 Arithmetic Expressions
    3.5 Comparison Expressions
        3.5.1 Value Comparisons
        3.5.2 General Comparisons
        3.5.3 Node Comparisons
        3.5.4 Order Comparisons
    3.6 Logical Expressions
    3.7 Constructors
        3.7.1 Element Constructors
        3.7.2 Computed Constructors
        3.7.3 Whitespace in Constructors
        3.7.4 Data Model Representation
            3.7.4.1 Constructed Element Nodes
            3.7.4.2 Constructed Attribute Nodes
        3.7.5 Other Constructors and Comments
    3.8 FLWR Expressions
    3.9 Order-Related Expressions
        3.9.1 Sort Expressions
        3.9.2 Unordered Expressions
    3.10 Conditional Expressions
    3.11 Quantified Expressions
    3.12 Expressions on SequenceTypes
        3.12.1 Instance Of
        3.12.2 Typeswitch
        3.12.3 Cast and Treat
    3.13 Validate Expressions
4 The Query Prolog
    4.1 Namespace Declarations
    4.2 Schema Imports
    4.3 Xmlspace Declaration
    4.4 Default Collation
    4.5 Function Definitions
5 Example Applications
    5.1 Joins
    5.2 Grouping
    5.3 Queries on Sequence
    5.4 Recursive Transformations

Appendices

A Grammar
    A.1 Lexical structure
        A.1.1 Syntactic Constructs
        A.1.2 Lexical Rules
    A.2 BNF
    A.3 Reserved Words
    A.4 Precedence Order
B Type Promotion and Operator Mapping
    B.1 Type Promotion
    B.2 Operator Mapping
C References
    C.1 Normative References
    C.2 Non-normative References
    C.3 Background References
    C.4 Informative Material
D Glossary
E XPath 2.0 and XQuery 1.0 Issues (Non-Normative)
F Revision Log (Non-Normative)
    F.1 16 Aug 2002
    F.2 10 Apr 2002
    F.3 20 Dec 2001


1 Introduction

As increasing amounts of information are stored, exchanged, and presented using XML, the ability to intelligently query XML data sources becomes increasingly important. One of the great strengths of XML is its flexibility in representing many different kinds of information from diverse sources. To exploit this flexibility, an XML query language must provide features for retrieving and interpreting information from these diverse sources.

XQuery is designed to meet the requirements identified by the W3C XML Query Working Group [XML Query 1.0 Requirements] and the use cases in [XML Query Use Cases]. It is designed to be a language in which queries are concise and easily understood. It is also flexible enough to query a broad spectrum of XML information sources, including both databases and documents. The Query Working Group has identified a requirement for both a human-readable query syntax and an XML-based query syntax. XQuery is designed to meet the first of these requirements. XQuery is derived from an XML query language called Quilt [Quilt], which in turn borrowed features from several other languages, including XPath 1.0 [XPath 1.0], XQL [XQL], XML-QL [XML-QL], SQL [SQL], and OQL [ODMG].

XQuery Version 1.0 is an extension of XPath Version 2.0. Any expression that is syntactically valid and executes successfully in both XPath 2.0 and XQuery 1.0 will return the same result in both languages. Since these languages are so closely related, their grammars and language descriptions are generated from a common source to ensure consistency, and the editors of these specifications work together closely.

XQuery also depends on and is closely related to the following specifications:

This document specifies a grammar for XQuery, using the same Basic EBNF notation used in [XML], except that grammar symbols always have initial capital letters. Unless otherwise noted, whitespace is not significant in the grammar. Grammar productions are introduced together with the features that they describe, and a complete grammar is also presented in the appendix [A Grammar].

In the grammar productions in this document, nonterminal symbols are underlined and literal text is enclosed in double quotes. Angle brackets are used to enclose tokens that must be recognized by using lexical look-ahead, as described in A.1 Lexical structure. For example, the following production describes the syntax of a function call:

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

The production should be read as follows: A function call consists of a QName followed by an open-parenthesis (these tokens must be recognized together using lexical lookahead.) The open-parenthesis is followed by an optional argument list. The argument list (if present) consists of one or more expressions, separated by commas. The optional argument list is followed by a close-parenthesis.

[Ed. Note: A future version of this document will include links between terms (in bold font) and their definitions.]

2 Basics

The basic building block of XQuery is the expression. The language provides several kinds of expressions which may be constructed from keywords, symbols, and operands. In general, the operands of an expression are other expressions. XQuery is a functional language which allows various kinds of expressions to be nested with full generality. It is also a strongly-typed language in which the operands of various expressions, operators, and functions must conform to designated types.

Like XML, XQuery is a case-sensitive language. All keywords in XQuery use lower-case characters.

The value of an expression is always a sequence, which is an ordered collection of zero or more items. An item is either an atomic value or a node. An atomic value is a value in the value space of an XML Schema atomic type, as defined in [XML Schema] (that is, a simple type that is not a list type or a union type). A node conforms to one of the seven node kinds described in [XQuery 1.0 and XPath 2.0 Data Model]. Each node has a unique node identity. Some kinds of nodes have typed values, string values, and names, which can be extracted from the node. The typed value of a node is a sequence of zero or more atomic values. The string value of a node is a value of type xs:string. The name of a node is a value of type xs:QName.

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.

In this document, the namespace prefixes xs: and xsi: are considered to be bound to the XML Schema namespaces http://www.w3.org/2001/XMLSchema and http://www.w3.org/2001/XMLSchema-instance, respectively (as described in [XML Schema]), and the prefix xf: is considered to be bound to the namespace of XPath/XQuery functions, http://www.w3.org/2002/08/xquery-functions (described in [XQuery 1.0 and XPath 2.0 Functions and Operators]). In some cases, where the meaning is clear and namespaces are not important to the discussion, built-in XML Schema typenames such as integer and string will be used without a namespace prefix.

2.1 Expression Context

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 two categories called the static context and the evaluation context.

This section describes the context information used by XQuery expressions, including the functions in the core function library. Other functions, outside the core function library, may require additional context information.

2.1.1 Static Context

The static context of an expression is the information that is available during static analysis of the expression, prior to its evaluation. This information can be used to decide whether the expression contains a static error.

In XQuery, the information in the static context is provided by declarations in the Query Prolog (except as noted below). Static context consists of the following components:

  • In-scope namespaces. This is a set of (prefix, URI) pairs. The in-scope namespaces are used for resolving prefixes used in QNames within the expression.

  • Default namespace for element and type names. This is a namespace URI. This namespace is used for any unprefixed QName appearing in a position where an element or type name is expected.

  • Default namespace for function names. This is a namespace URI. This namespace is used for any unprefixed QName appearing as the function name in a function call.

  • In-scope schema definitions. This is a set of (QName, type definition) pairs. It defines the set of types that are available for reference within the expression. It includes the built-in schema types and all globally-declared types in imported schemas. It may also include types declared in schemas associated with documents retrieved by input functions, as described in 2.2 Input Functions.

    Ed. Note: The importing of type definitions from input documents is still under discussion. The idea that the static context should be affected by run-time functions in an implementation-defined way remains controversial (see Issue 307.)

  • In-scope variables. This is a set of (QName, type) pairs. It defines the set of variables that have been declared and are available for reference within the expression. The QName represents the name of the variable, and the type represents its static data type.

    Unlike the other parts of the static context, variable types are not declared in the Query Prolog. Instead, they are derived from static analysis of the expressions in which the variables are bound.

  • In-scope functions. This part of the static context defines the set of functions that are available to be called from within an expression. Each function is uniquely identified by its QName and its arity (number of parameters). The static context maps QName and arity into a function signature, which specifies the static types of the function parameters and function result.

  • In-scope collations. This is a set of (URI, collation) pairs. It defines the names of the collations that are available for use in function calls that take a collation name as an argument. A collation may be regarded as an object that supports two functions: a function that given a set of strings, returns a sequence containing those strings in sorted order; and a function that given two strings, returns true if they are considered equal, and false if not.

  • Default collation. This is a collation. This collation is used by string comparison functions when no explicit collation is specified.

  • Base URI. This is an absolute URI, used by the xf:document function when resolving the relative URI of a document to be loaded, if no explicit base URI is supplied in the function call.

2.1.2 Evaluation Context

The evaluation context of an expression is defined as information that is available at the time the expression is evaluated. The evaluation context consists of all the components of the static context, and the additional components listed below.

The first three components of the dynamic context (context item, context position, and context size) are called the focus of the expression. The focus enables the processor to keep track of which nodes are being processed by the expression.

The focus for the outermost expression is supplied by the environment in which the expression is evaluated. Certain language constructs, notably the path expression E1/E2, the predicate expression E1[E2], and the ordering expression E1 sort by (E2), create a new focus for the evaluation of a sub-expression. In these constructs, E2 is evaluated once for each item in the sequence that results from evaluating E1. Each time E2 is evaluated, it is evaluated with a different focus. The focus for evaluating E2 is referred to below as the inner focus, while the focus for evaluating E1 is referred to as the outer focus. The inner focus exists only while E2 is being evaluated. When this evaluation is complete, evaluation of the containing expression continues with its original focus unchanged. [Ed. Note: See issue 216.]

  • The context item is the item currently being processed. An item is either an atomic value or a node. When the context item is a node, it can also be referred to as the context node. The context item is returned by the expression ".". When an expression E1/E2, E1[E2] or E2 sort by (E2) is evaluated, each item in the sequence obtained by evaluating E1 becomes the context item in the inner focus for an evaluation of E2.

  • The context position is the position of the context item within the sequence of items currently being processed. It changes whenever the context item changes. Its value is always an integer greater than zero. The context position is returned by the expression xf:position(). When an expression E1/E2, E1[E2], or E1 sort by (E2) is evaluated, the context position in the inner focus for an evaluation of E2 is the position of the context item in the sequence obtained by evaluating E1. The position of the first item in a sequence is always 1 (one). The context position is always less than or equal to the context size.

  • The context size is the number of items in the sequence of items currently being processed. Its value is always an integer greater than zero. The context size is returned by the expression last(). When an expression E1/E2, E1[E2], or E1 sort by (E2) is evaluated, the context size in the inner focus for an evaluation of E2 is the number of items in the sequence obtained by evaluating E1.

  • Dynamic variables. This is a set of (QName, type, value) triples. It contains the same QNames as the in-scope variables in the static context for the expression. Each QName is associated with the dynamic type and value of the corresponding variable. The dynamic type associated with the value of a variable may be more specific than the static type associated with the same variable. The value of a variable is, in general, a sequence.

    The dynamic types and values of variables are provided by execution of the XQuery expressions in which the variables are bound.

  • Current date and time. This information represents an implementation-defined point in time during processing of a query or transformation. It can be retrieved by the xf:current-date, xf:current-time, and xf:current-dateTime functions. If invoked multiple times during the execution of a query or transformation, these functions always returns a consistent result.

  • Implicit timezone. This is the timezone to be used when a date, time, or dateTime value that does not have a timezone is used in a comparison or in any other operation. This value is an instance of dayTimeDuration that is implementation-defined. See [ISO 8601] for the range of legal values of a timezone.

  • Input sequence. The input sequence is sequence of nodes that can be accessed by the input function. It might be thought of as an "implicit input". The content of the input sequence is determined in an implementation-defined way.

2.2 Input Functions

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

The input sequence is a part of the evaluation context for an expression. The way in which nodes are assigned to the input sequence is implementation-defined. For instance, one implementation might provide a fixed mapping from a directory system to the input sequence, another implementation might provide a graphical user interface that allows users to choose a data source for the input sequence, and a third implementation might support UNIX-style pipes, allowing the output of one query to become the input sequence for another query.

The input function, which takes no parameters, returns the input sequence. For example, the expression input()//customer returns all the customer elements that are descendants of nodes in the input sequence. If no input sequence has been bound, the input function raises a dynamic error.

The collection function returns the nodes found in a collection. A collection may be any sequence of nodes. A collection is identified by a string, which must be a valid URI. For example, the expression collection("http://example.org")//customer identifies all the customer elements that are descendants of nodes found in the collection whose URI is http://example.org.

The document function, when its first argument is a string containing a single URI that refers to an XML document, returns the root of that document. The document function can also be used to address multiple documents or document fragments; see [XQuery 1.0 and XPath 2.0 Functions and Operators] for details.

The input functions described in this section provide access to input documents or document fragments. If these documents or document fragments are associated with schemas, the type definitions contained in these schemas may be added to the in-scope schema definitions, in an implementation-defined way.

Ed. Note: The importing of type definitions from input documents is still under discussion. The idea that the static context should be affected by run-time functions in an implementation-defined way remains controversial (see Issue 307).

2.3 Expression Processing

XQuery is defined in terms of the [XQuery 1.0 and XPath 2.0 Data Model] (referred to in this document simply as the Data Model), which represents information in the form of nodes and atomic values. Before an XQuery expression can be processed, the input documents to be operated on by the expression must be represented in the Data Model. For example, an XML document can be converted to the Data Model by the following steps:

  1. The document can be parsed using an XML parser.

  2. The parsed document can be validated against one or more schemas. This process, which is described in [XML Schema], results in an abstract information structure called the Post-Schema Validation Infoset (PSVI). If a document has no associated schema, it can be validated against a permissive default schema that accepts any well-formed document.

  3. The PSVI can be transformed into the Data Model by a process described in [XQuery 1.0 and XPath 2.0 Data Model].

The above steps provide an example of how a Data Model instance might be constructed. A Data Model instance might also be synthesized directly from a relational database, or constructed in some other way. XQuery is defined in terms of operations on the Data Model, but it does not place any constraints on how the input Data Model instance is constructed.

Each element or attribute node in the Data Model has an annotation that indicates its dynamic type. If the Data Model was derived from an input XML document, the dynamic types of the elements and attributes are derived from schema validation. A newly constructed element node has the dynamic type xs:anyType, and a newly constructed attribute node has the dynamic type xs:anySimpleType. Constructed element and attribute nodes may be given a more specific type annotation by a validate expression. The dynamic type of an element or attribute indicates its range of values--for example, an attribute named version might have the dynamic type xs:decimal, indicating that it contains a decimal value.

The value of an attribute is represented directly within the attribute node. An attribute node whose type is unknown (such as might occur in a schemaless document) is annotated with the dynamic type xs:anySimpleType.

The value of an element is represented by the children of the element node, which may include text nodes and other element nodes. The dynamic type of an element node indicates how the values in its child text nodes are to be interpreted. An element whose type is unknown (such as might occur in a schemaless document) is annotated with the type xs:anyType.

Atomic values in the Data Model also carry dynamic type annotations. An atomic value of unknown type is annotated with the type xs:anySimpleType. Under certain circumstances (such as during processing of an arithmetic operator), an atomic value of xs:anySimpleType may be cast into a more specific type (such as xs:double).

This document provides a description of how each kind of expression is processed. For each expression, the operands and result are instances of the Data Model. The details of transforming XML documents into the Data Model are described in [XQuery 1.0 and XPath 2.0 Data Model]. Transformation of a Data Model instance into an XML document is currently an open issue.

The terms document order, typed value, and string value are described here because they are of particular importance for the processing of expressions.

2.3.1 Document Order

Document order defines a total ordering among all the nodes seen by the language processor. Within a given document, the document node is the first node, followed by element nodes, text nodes, comment nodes, and processing instruction nodes in the order of their representation in the XML form of the document (after expansion of entities). Element nodes occur before their children. The namespace nodes of an element immediately follow the element node, in implementation-defined order. The attribute nodes of an element immediately follow its namespace nodes, and are also in implementation-defined order.

The relative order of nodes in distinct documents is implementation-defined but stable within a given query or transformation. In other words, given two distinct documents A and B, if a node in document A is before a node in document B, then every node in document A is before every node in document B. The relative order among free-floating nodes (those not in a document) is implementation-defined.

2.3.2 Typed Value and String Value

Element, attribute, and text nodes have a typed value and a string value that can be extracted by calling the data function and the string function, respectively. The typed value of a node is a sequence of atomic values, and the string value of a node is a string. Element and attribute nodes also have a type annotation, which is a QName that is defined in the in-scope schema definitions. The type annotation of a node is assigned when the node is constructed, and can be changed by validating the node (see 3.13 Validate Expressions).

The typed value and string value for each kind of node are defined by the dm:typed-value and dm:string-value accessors in [XQuery 1.0 and XPath 2.0 Data Model]. Specifically:

  1. The typed value of a text node is the same as its string value, as an instance of xs:anySimpleType.

  2. If the type annotation of an attribute node is xs:anySimpleType, its typed value is equal to its string value, as an instance of xs:anySimpleType. Otherwise, its typed value is derived from its string value and type annotation in a way that is consistent with schema validation, as described in [XQuery 1.0 and XPath 2.0 Data Model].

    • Example: A1 is an unvalidated attribute whose content is defined by the expression {2 + 2}. The type annotation of A1 is xs:anySimpleType. The string value of A1 is "4". The typed value of A1 is "4" as an instance of xs:anySimpleType. If A1 is later validated and found to have the type hatsize, its string value is still "4", but its typed value is 4 as an instance of hatsize.

    • Example: A2 is a validated attribute with type annotation IDREFS, which is a list type derived from IDREF. Its string value is "bar baz faz". The typed value of A2 is a sequence of three atomic values ("bar", "baz", "faz"), each of type IDREF.

  3. If the type annotation of an element node is xs:anyType, its typed value is equal to its string value, as an instance of xs:anySimpleType. Otherwise, its typed value is derived from its string value and type annotation in a way that is consistent with schema validation, as described in [XQuery 1.0 and XPath 2.0 Data Model]. If the type annotation of an element denotes a type with complex content (i.e., a type that permits subelements), its typed value is undefined, and the data function raises an error when applied to such an element.

    • Example: E1 is an unvalidated element node whose content is defined by the expression {1, 2, 3}. The type annotation of E1 is xs:anyType. The string value of E1 is the string "1 2 3". The typed value of E1 is "1 2 3" as an instance of xs:anySimpleType.

    • Example: E2 is a validated element node with the type annotation hatsizelist, which is a complex type whose content is defined as a sequence of items of type hatsize, which in turn is derived from xs:integer. The string value of E2 is "7 8 9". The typed value of E2 is a sequence of three values (7, 8, 9), each of type hatsize.

    • Example: E3 is a validated element node with the type annotation weather, which is a complex type that permits subelements. The string value of E3 is "hot". Even though E3 does not happen to contain any subelements, its typed value is undefined because its type permits subelements.

2.4 Types

XQuery is a strongly typed language with a type system based on [XML Schema]. The built-in types of XQuery include the node kinds of XML (such as element, attribute, and text nodes), the built-in atomic types of [XML Schema] (such as xs:integer and xs:string), and the following special derived types: xf:dayTimeDuration and xf:yearMonthDuration (described in [XQuery 1.0 and XPath 2.0 Functions and Operators]). Additional types may be defined in schemas and imported into a query by means of a schema import, as discussed in 4.2 Schema Imports.

When the type of a value is not appropriate for the context in which it is used, a type exception is raised. Languages that are based on XPath 2.0 may handle type exceptions with either a strict or a flexible policy, as described in [XPath 2.0]. XQuery has a strict type exception policy, which means that all type exceptions are treated as errors.

Like XML Schema, XQuery distinguishes named types from anonymous types. The set of named types includes all the built-in types and all user-defined simple or complex types for which the type declaration contains a name. For example, named types may be associated with values in one of the following ways:

  • A literal value has a named type; for example, the type of the value 47 is xs:integer.

  • The constructor functions described in [XQuery 1.0 and XPath 2.0 Functions and Operators] return values with named types; for example, xs:date("2002-5-31") returns a value of type xs:date.

  • When an instance of the Data Model is constructed from a validated document, type names assigned by a schema processor are preserved in the Data Model.

  • The validate expression invokes schema validation within a query, assigning type names in the same way that a schema processor would.

  • The cast expression creates an atomic value with a specific named type.

  • Some functions, such as data(), extract typed values from the nodes of a document, preserving the named types of these values.

The XQuery type system is formally defined in [XQuery 1.0 Formal Semantics]. This section presents a summary of types from a user's perspective.

2.4.1 Type Checking

XQuery defines two phases of processing called the analysis phase and the evaluation phase.

The analysis phase depends on the query expression itself and on the static context. The analysis phase does not depend on any input data. The purpose of type-checking during the analysis phase is to provide early detection of type errors and to compute the type of a query result.

During the analysis phase, each expression is assigned a static type. In some cases, the static type is derived from the lexical form of the expression; for example, the static type of the literal 5 is xs:integer. In other cases, the static type of an expression is inferred according to rules based on the static types of its operands; for example, the static type of the expression size < 5 is xs:boolean. The static type of an expression may be either a named type or a structural description--for example, xs:boolean? denotes an optional occurrence of the xs:boolean type. The rules for inferring the static types of various expressions are described in [XQuery 1.0 Formal Semantics]. During the analysis phase, if an operand of an expression is found to have a static type that is not appropriate for that operand, a static type error is raised. If static type checking raises no errors and assigns a static type T to an expression, then execution of the expression on valid input data is guaranteed to produce either a value of type T or to raise a dynamic type error.

The evaluation phase is performed only after successful completion of the analysis phase. The evaluation phase depends on input data, on the expression being evaluated, and on the evaluation context. During the evaluation phase, a dynamic type is associated with each value as it is computed. The dynamic type of a value may be either a structural type (such as "sequence of integers") or a named type. The dynamic type of a value may be more specific than the static type of the expression that computed it (for example, the static type of an expression might be "zero or more integers or strings," but at run time its value may have the dynamic type "integer.") If an operand of an expression is found to have a dynamic type that is not appropriate for that operand, a type exception is raised.

It is possible for analysis of an expression to raise a static type error, even though the expression might evaluate successfully on some valid input data. For example, an expression might contain a function that requires an element as its parameter, and the analysis phase might infer the static type of the function parameter to be an optional element. In this case, a static type error would result, even though the function call would be successful for input data in which the optional element is present.

It is also possible for an expression to raise a dynamic error, even though analysis of the expression raised no static error. For example, an expression may contain a cast of a string into an integer, which is statically valid. However, if the actual value of the string at run time cannot be cast into an integer, a dynamic error will result. Similarly, an expression may apply an arithmetic operator to a value extracted from a schemaless document. This is not a static error, but at run time, if the value cannot be successfully cast to a numeric type, a dynamic error will be raised.

If an implementation can determine by static analysis that an expression will necessarily raise a dynamic error (for example, because it attempts to construct a decimal value from a constrant string that is not a valid decimal value), the implementation is allowed to report this error during the analysis phase (as well as during the evaluation phase).

2.4.2 SequenceType

When it is necessary to refer to a type in an XQuery expression, the syntax shown below is used. This syntax production is called "SequenceType", since it describes the type of an XQuery value, which is a sequence.

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

Here are some examples of SequenceTypes that might be used in XQuery expressions or function parameters:

  • xs:date refers to the built-in Schema type date

  • attribute? refers to an optional attribute

  • element refers to any element

  • element office:letter refers to an element that has a specific name and that has been validated as conforming to the schema definition for that name

  • element of type po:address+ refers to one or more elements that have been validated as conforming to the schema definition of the given type

  • node* refers to a sequence of zero or more nodes of any type

  • item* refers to a sequence of zero or more nodes or atomic values

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. For example, an instance of expression returns true if a given value matches a given type, or false if it does not.

SequenceType matching between a given value and a given SequenceType is performed as follows:

If the SequenceType is empty, the match succeeds only if the value is an empty sequence. If the SequenceType is an ItemType with no OccurrenceIndicator, the match succeeds only if the value contains precisely one item and that item matches the ItemType (see below). If the SequenceType contains an ItemType and an OccurrenceIndicator, the match succeeds only if the number of items in the value matches the OccurrenceIndicator and each of these items matches the ItemType. As a consequence of these rules, a value that is an empty sequence matches any SequenceType whose occurrence indicator is * or ?.

An OccurrenceIndicator indicates the number of items in a sequence, as follows:

  • ? indicates zero or one items

  • * indicates zero or more items

  • + indicates one or more items

The process of matching a given item against a given ItemType is performed as follows (remember that an item may be a node or an atomic value):

  1. The ItemType item matches any item. For example, item matches the atomic value 1 or the element <a/>.

  2. The following ItemTypes match atomic values:

    1. atomic value matches any atomic value.

    2. A named atomic type matches a value if the dynamic type of the value is the same as the named atomic type or is derived from the named atomic type by restriction. For example, the ItemType xs:decimal matches the value 12.34 (a decimal literal); it also matches a value whose dynamic type is shoesize, if shoesize is an atomic type derived from xs:decimal.

    3. untyped matches an atomic value whose most specific type is xs:anySimpleType.

  3. The following ItemTypes match nodes:

    1. node matches any node.

    2. text matches any text node.

    3. processing-instruction matches any processing instruction node.

    4. comment matches any comment node.

    5. document matches any document node.

    6. element matches an element node. Optionally, element may be followed by ElemOrAttrType,which places further constraints on the node (see below).

    7. attribute matches an attribute node. Optionally, attribute may be followed by ElemOrAttrType,which places further constraints on the node (see below).

An ElemOrAttrType may be used to place a constraint on the name or type of an element or attribute, as follows:

  1. One form of ElemOrAttrType, denoted by the phrase "of type", specifies the required type of the element or attribute node. The required type must be the QName of a simple or complex type that is found in the in-scope schema definitions. The match is successful only if the given element or attribute has a type annotation that is the same as the required type or is known (in the in-scope schema definitions) to be derived from the required type. For example, element of type Employee matches an element node that has been validated and has received the type annotation Employee. Similarly, attribute of type xs:integer matches an attribute node that has been validated and has received the type annotation xs:integer.

  2. Another form of ElemOrAttrType is simply a QName, which is interpreted as the required name of the element or attribute. The QName must be an element or attribute name that is found in the in-scope schema definitions. The match is successful only if the given element or attribute has the required name and also conforms to the schema definition for the required name. This can be verified in either of the following ways:

    1. If the schema definition for the required name has a named type, the given element or attribute must have a type annotation that is the same as that named type or is known (in the in-scope schema definitions) to be derived from that named type. For example, suppose that a schema declares the element named location to have the type State. Then the SequenceType element location will match a given element only if its name is location and its type annotation is State or some named type that is derived from State.

    2. If the schema definition for the required name has an anonymous (unnamed) type definition, the actual content of the given element or attribute must structurally comply with this type definition. For example, suppose that a schema declares the element named shippingAddress to have an anonymous complex type consisting of a street element followed by a city element. Then the SequenceType element shippingAddress will match a given element only if its name is shippingAddress and its content is a street element followed by a city element.

    The constraint that an element must have a required name is considered to be satisfied if the element has been validated and found to be a member of a substitution group whose head element has the required name. Substitution groups are described in [XML Schema].

  3. The above two forms of ElemOrAttrType may be combined to specify both the required name and the required type of an element or attribute node, as in element person of type Employee or attribute color of type xs:integer. This form might be used, for example, to specify a required type that is more specific than the schema type associated with the required name.

In some cases, the required name of an element or attribute node may be locally declared (that is, declared inside a complex type in some schema.) In this case, the ElemOrAttrType may specify the SchemaContext in which the required name is to be interpreted. For example, element shippingAddress in invoice/customer matches an element node that conforms to the schema definition of the element name shippingAddress, as it would be interpreted inside a customer element that is inside an invoice element. The first QName in the SchemaContext must be found in the in-scope schema definitions.

2.4.3 Type Conversions

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 3.1.4 Function Calls. Other operators that provide special conversion rules include arithmetic operators, which are discussed in 3.4 Arithmetic Expressions, and value comparisons, which are discussed in 3.5.1 Value Comparisons.

2.4.3.1 Atomization

Type conversions sometimes depend on a process called atomization, which is used when an optional atomic value is expected. When atomization is applied to a given value, the result is either a single atomic value, an empty sequence, or a type exception. Atomization is defined as follows:

  • If the value is a single atomic value or an empty sequence, atomization simply returns the value.

  • If the value is a single node, the typed value of the node is extracted and returned; however, if the typed value is a sequence containing more than one item, a type exception is raised.

  • In any other case, atomization raises a type exception.

Atomization may be used in processing the following types of expressions:

  • Arithmetic expressions

  • Comparison expressions

  • Function calls and returns

  • Cast expressions

  • Sort expressions

2.4.3.2 Effective Boolean Value

If a sequence of items is encountered where a boolean value is expected, it is necessary to find its effective boolean value. The effective boolean value of a sequence is defined as follows:

  • If the sequence is empty, its effective boolean value is false.

  • If the sequence contains a single atomic value of type xs:boolean, this value is the effective boolean value of the sequence.

  • If the sequence contains at least one node, its effective boolean value is true.

  • In any other case, a type exception is raised. In XQuery, a type exception always raises a dynamic error.

The effective boolean value of a sequence may be computed during the processing of the following types of expressions:

  • Logical expressions (and, or)

  • The xf:not function

  • The where clause of a FLWR expression

  • Conditional expressions (if)

  • Quantified expressions (some, every)

2.5 Errors and Conformance

2.5.1 Errors

As described in 2.4.1 Type Checking, XQuery defines an analysis phase, which does not depend on input data, and an evaluation phase, which does depend on input data.

The result of the analysis phase is either success or one or more static errors. Some static errors are static type errors, which occur when the static type of an expression is not correct for the context in which it appears. The term static errors also includes non-type-related errors such as syntax errors. The means by which static errors are reported is implementation-defined.

The result of the evaluation phase is either a result value or a dynamic error. Some dynamic errors are dynamic type errors, which occur when the dynamic type of an expression is not correct for the context in which it appears. The term dynamic errors also includes non-type-related dynamic errors such as numeric overflow. If an implementation returns a value, the value must conform to the dynamic rules defined in [XQuery 1.0 Formal Semantics].

[XQuery 1.0 Formal Semantics] defines the set of static and dynamic errors. In addition to these errors, an XQuery implementation may raise implementation-defined warnings, either during the analysis phase or the evaluation phase. The way in which warnings are raised and handled is implementation-defined.

2.5.2 Conformance

XQuery defines a basic conformance level named Basic XQuery, and two optional features called the Schema Import Feature and the Static Typing Feature. A conforming implementation must satisfy the requirements of Basic XQuery, and may also provide either or both of the optional features.

2.5.2.1 Basic XQuery

A conforming Basic XQuery implementation must implement the full XQuery language, subject to the following limitations:

  1. If a QueryProlog contains a SchemaImport, a Basic XQuery implementation raises a static error.

  2. In a Basic XQuery implementation, the in-scope schema definitions consist of a fixed set of 48 predefined type definitions. These include the 44 built-in datatypes defined in [XML Schema], plus four additional types: xf:yearMonthDuration, xf:dayTimeDuration, xs:anySimpleType, and xs:anyType.

  3. A mapping from a Post-Schema Validation Infoset (PSVI) to the Query Data Model is specified in [XQuery 1.0 and XPath 2.0 Data Model]. In a Basic XQuery implementation, this mapping maps each datatype that is not one of the 48 predefined types listed above into its nearest supertype that belongs to this list. As a result of this mapping, all complex types are mapped into xs:anyType. (Of course, mapping from a PSVI is only one way in which a Query Data Model instance might be constructed--other ways are also possible.)

  4. If any SequenceType contains an AtomicType that is not one of the 48 predefined types listed above, a Basic XQuery implementation raises a static error.

  5. If any SequenceType contains an ElemOrAttrType, a Basic XQuery implementation raises a static error.

  6. If the processing of an expression depends on the type of some value, and that type is not one of the 48 predefined types listed above, a Basic XQuery implementation raises a dynamic error.

  7. A Basic XQuery implementation is not required to raise static type errors during the analysis phase. If an expression contains one or more non-type-related static errors, then a Basic XQuery implementation must raise at least one of these static errors during the analysis phase. If the analysis phase is successful but one or more dynamic errors are encountered during the evaluation phase, then a Basic XQuery implementation must raise at least one of these dynamic errors.

2.5.2.2 Schema Import Feature

The Schema Import Feature removes the limitations specified by Rules 1 through 6 of Basic XQuery.

During the analysis phase, in-scope schema definitions are derived from schemas named in Schema Import clauses. If more than one schema is imported, the definitions contained in these schemas are collected into a single pool of definitions. This pool of definitions must satisfy the conditions for schema validity set out in Sections 3 and 5 of [XML Schema] Part 1. In brief, the definitions must be valid, they must be complete and they must be unique--that is, the pool of definitions must not contain two or more schema components with the same name and target namespace. If any of these conditions is violated, a static error must be raised.

2.5.2.3 Static Typing Feature

The Static Typing Feature removes the limitation specified by Rule 7 of Basic XQuery. An implementation that includes this feature is required to detect static type errors. If an expression contains one or more static errors, including static type errors, then a Static Typing implementation must raise at least one of these static errors during the analysis phase.

Ed. Note: The Working Group is currently discussing the relationships among the various XQuery features (for example, if an expression executes successfully on an implementation with Feature A, will it also execute successfully on an implementation with Feature B?). The Working Group is also discussing the issue of "type soundness" (that is, if the Static Typing Feature is implemented and a given expression raises no static errors, what guarantees can be made about its behavior during the evaluation phase?). The editors expect to include more material on these issues in a future version of this document. (See Issue 308.)

2.5.3 Handling Dynamic Errors

Except as noted in this document, if any operand of an expression raises a dynamic error, the expression also raises a dynamic error. If an expression can validly return a value or raise a dynamic error, the implementation may choose to return the value or raise the dynamic error. For example, the logical expression expr1 and expr2 may return the value false if either operand returns false, or may raise a dynamic error if either operand raises a dynamic error.

If more than one operand of an expression may raise an error, the implementation may choose which error is raised by the expression. For example, in this expression:

($x div $y) + xsd:decimal($z)

both ($x div $y) and xsd:decimal($z) may raise an error. The implementation may choose which error is raised by the "+" expression. Once one operand raises an error, the implementation is not required, but is permitted, to evaluate any other operands.

A dynamic error carries an error value, which may be a single item or an empty sequence. For example, an error value might be an integer, a string, a QName, or an element. An implementation may provide a mechanism whereby an application-defined error handler can process error values and produce diagnostics; in the absence of such an error handler, the string-value of the error value may be used directly as an error message.

A dynamic error may be raised by a built-in function or operator. For example, the input function raises an error if the input sequence is not defined in the evaluation context.

An error can be raised explicitly by calling the xf:error function, which only raises an error and never returns a value. The xf:error function takes an optional item as its parameter, which is used as the error value. For example, the following function call raises a dynamic error whose error value is a string:

xf:error(xf:concat("Unexpected value ", $v))

3 Expressions

This section introduces each of the basic kinds of XQuery expression. Each kind of expression has a name such as PathExpr, which is introduced on the left side of the grammar production that defines the expression. Since XQuery is a composable language, each kind of expression is defined in terms of other expressions whose operators have a higher precedence. In this way, the precedence of operators is represented explicitly in the grammar.

The simplest kinds of expressions are introduced first, followed by more complex expressions. This order of presentation does not conform to the order of operator precedence. The complete grammar is presented in the appendix [A Grammar].

The highest-level kind of expression (that is, the kind of expression whose operators have lowest precedence) is SortExpr, which is defined in 3.9.1 Sort Expressions.

[5]   Expr   ::=   SortExpr

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

[39]   PrimaryExpr   ::=   Literal |  FunctionCall |  ("$" VarName) |  ParenthesizedExpr
[228]   VarName   ::=   QName

3.1.1 Literals

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

[56]   Literal   ::=   NumericLiteral |  StringLiteral
[55]   NumericLiteral   ::=   IntegerLiteral |  DecimalLiteral |  DoubleLiteral
[194]   IntegerLiteral   ::=   Digits
[195]   DecimalLiteral   ::=   ("." Digits) |  (Digits "." [0-9]*)
[196]   DoubleLiteral   ::=   (("." Digits) |  (Digits ("." [0-9]*)?)) ("e" | "E") ("+" | "-")? Digits
[215]   StringLiteral   ::=   ('"' (('"' '"') |  [^"])* '"') |  ("'" (("'" "'") |  [^'])* "'")

The value of a string literal is a singleton sequence containing an item whose primitive type is xs:string and whose value is the string denoted by the characters between the delimiting quotation marks. If the literal is delimited by single quotes, two adjacent single quote characters within the literal are interpreted as one single quote character. Similarly, if the literal is delimited by double quotes, two adjacent double quote characters within the literal are interpreted as one double quote character.

The value of a numeric literal containing no "." and no e or E character is a singleton sequence containing an item whose type is xs:integer and whose value is obtained by parsing the numeric literal according to the rules of the xs:integer datatype. The value of a numeric literal containing "." but no e or E character is a singleton sequence containing an item whose primitive type is xs:decimal and whose value is obtained by parsing the numeric literal according to the rules of the xs:decimal datatype. The value of a numeric literal containing an e or E character is a singleton sequence containing an item whose primitive type is xs:double and whose value is obtained by parsing the numeric literal according to the rules of the xs:double datatype.

Here are some examples of literal expressions:

  • "12.5" denotes the string containing the characters '1', '2', '.', and '5'.

  • 12 denotes the integer value twelve.

  • 12.5 denotes the decimal value twelve and one half.

  • 125E2 denotes the double value twelve thousand, five hundred.

The boolean values true and false can be represented by calls to the built-in functions xf:true() and xf:false(), respectively.

Values of other XML Schema built-in types can be constructed by calling the constructor for the given type. The constructors for XML Schema built-in types are defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. In general, the name of a constructor function for a given type is the same as the name of the type (including its namespace). For example:

  • xs:integer("12") returns the integer value twelve.

  • xs:date("2001-08-25") returns an item whose type is xs:date and whose value represents the date 25th August 2001.

  • xf:dayTimeDuration("PT5H") returns an item whose type is xf:dayTimeDuration and whose value represents a duration of five hours.

It is also possible to construct values of various types by using a cast expression. For example:

  • cast as hatsize(9) returns an item whose primitive value is the integer 9 and whose type is the user-defined type hatsize, derived from xs:integer.

3.1.2 Variables

A variable evaluates to the value to which its name is bound in the evaluation context. An expression containing an unbound variable raises a static error. Variables can be bound by clauses in for expressions and quantified expressions, and by function calls, which bind values to the formal parameters of functions before executing the function body.

3.1.3 Parenthesized Expressions

[57]   ParenthesizedExpr   ::=   "(" ExprSequence? ")"

Parentheses may be used to enforce a particular evaluation order in expressions that contain multiple operators. For example, the expression (2 + 4) * 5 evaluates to thirty, since the parenthesized expression (2 + 4) is evaluated first and its result is multiplied by five. Without parentheses, the expression 2 + 4 * 5 evaluates to twenty-two, because the multiplication operator has higher precedence than the addition operator.

Empty parentheses are used to denote an empty sequence, as described in 3.3.1 Constructing Sequences.

3.1.4 Function Calls

A function call consists of a QName followed by a parenthesized list of zero or more expressions, called arguments. The QName and number of arguments must match the name and arity of an in-scope function in the static context (see 2.1 Expression Context); otherwise, a static error is raised.

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

A function call expression is evaluated as follows:

  1. Each argument expression is evaluated, producing an argument value.

  2. Each argument value is converted to the declared type of the corresponding function parameter, using the function conversion rules listed below.

  3. If the function is a built-in function, it is executed using the converted argument values. The result is a value of the function's declared return type.

  4. If the function is a user-defined function, the converted argument values are bound to the formal parameters of the function, and the function body is evaluated. The value returned by the function body is then converted to the declared return type of the function by applying the function conversion rules.

    A function does not inherit a focus (context item, context position, and context size) from the environment of the function call. During evaluation of a function body, the focus is undefined, except where it is defined by the action of some expression inside the function body. Use of an expression that depends on the focus when the focus is undefined results in a dynamic error.

The function conversion rules are used to convert an argument value or a return value to its required type; that is, to the declared type of the function parameter or return. The required type is expressed as a SequenceType. The function conversion rules are as follows:

  1. If the required type is an AtomicType:

    Atomization is applied to the given value. If the resulting atomic value is of type xs:anySimpleType, an attempt is made to cast it to the required type; if the cast fails, the function call raises a dynamic type error. If the atomic value has a type that can be promoted to the required type using the promotion rules in B.1 Type Promotion, the promotion is done.

  2. If the required type is a sequence or optional occurrence of AtomicType:

    If the given value contains any nodes, these nodes are replaced by their typed values. Each item is converted to the required AtomicType using the conversion rule for AtomicType.

  3. If the required type is any other SequenceType, or if no required type is declared:

    No conversion is performed.

If the Static Typing Feature is implemented, and the static type of a (converted) function argument or result, as inferred by the static type inference rules in [XQuery 1.0 Formal Semantics], is not a subtype of the required type, a static type error is raised. If the Static Typing Feature is not implemented, and the dynamic type of a (converted) function argument or result does not match the required type according to the rules for SequenceType Matching, a dynamic type error is raised.

A core library of functions is defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. Functions in this library may be invoked without a namespace prefix by assigning the default function namespace to the namespace of the function library.

The comma operator in XQuery serves two purposes: it separates the arguments in a function call, and it separates items in an expression that constructs a sequence (see 3.3.1 Constructing Sequences). To distinguish these two uses, parentheses can be used to delimit the individual arguments of a function call. Here are some illustrative examples of function calls:

  • three-argument-function(1, 2, 3) denotes a function call with three arguments.

  • two-argument-function((1, 2), 3) denotes a function call with two arguments, the first of which is a sequence of two values.

  • two-argument-function(1, ()) denotes a function call with two arguments, the second of which is an empty sequence.

  • one-argument-function((1, 2, 3)) denotes a function call with one argument that is a sequence of three values.

  • one-argument-function(( )) denotes a function call with one argument that is an empty sequence.

  • zero-argument-function( ) denotes a function call with zero arguments.

3.1.5 Comments

XQuery comments can be used to provide informative annotation. These comments are lexical constructs only, and do not affect the processing of an expression.

[94]   ExprComment   ::=   "{--" [^}]* "--}"

Comments may be used before and after major tokens within expressions and within element content. See A.1 Lexical structure for the exact lexical states where comments are recognized.

The following is an example of a comment:

{-- Houston, we have a problem --}

Ed. Note: The EBNF should disallow "--}" within the comment, rather than "}". Also, within an enclosed expression, a comment immediately after the opening "{" will cause the "{{" to be mistaken for an escaped "{". Thus, <a>{{--comment--}foo}</a> will currently cause an error, and must be disambiguated with a space between the "{" characters. This should be considered an open issue.

3.2 Path Expressions

A path expression can be used to locate nodes within a tree. Because the XQuery grammar is organized around the precedence of operators, the syntax for PathExpr also includes PrimaryExpr. In common usage, the term path expression denotes a PathExpr that is not simply a PrimaryExpr.

[23]   PathExpr   ::=   ("/" RelativePathExpr?) |  ("//" RelativePathExpr) |  RelativePathExpr
[24]   RelativePathExpr   ::=   StepExpr (("/" |  "//") StepExpr)*

A path expression consists of a series of one or more steps, separated by "/", and optionally beginning with "/" or "//". An initial "/" or "//" is an abbreviation for one or more initial steps that are implicitly added to the beginning of the path expression, as described below.

A path expression consisting of a single step is evaluated as described in 3.2.1 Steps.

In a path expression consisting of two or more steps, each occurrence of // is expanded as described in 3.2.4 Abbreviated Syntax, leaving a sequence of steps separated by /. This sequence of steps is then evaluated from left to right. Each operation E1/E2 is evaluated as follows: Expression E1 is evaluated, and if the result is not a sequence of nodes, a dynamic error is raised. The resulting sequence of nodes is sorted in document order, and duplicates are eliminated based on node identity. Each node resulting from the evaluation of E1 then serves in turn to provide an inner focus for an evaluation of E2, as described in 2.1.2 Evaluation Context. Each evaluation of E2 must result in a sequence of nodes; otherwise, a dynamic error is raised. The sequences of nodes resulting from all the evaluations of E2 are merged, eliminating duplicate nodes based on node identity and sorting the results in document order.

As an example of a path expression, child::div1/child::para selects the para element children of the div1 element children of the context node, or, in other words, the para element grandchildren of the context node that have div1 parents.

A "/" at the beginning of a path expression is an abbreviation for the initial step xf:root(self::node()). The effect of this initial step is to begin the path at the root node that contains the context node. If the context item is not a node, a dynamic error is raised.

A "//" at the beginning of a path expression is an abbreviation for the initial steps xf:root(self::node())/descendant-or-self:node(). The effect of these initial steps is to establish an initial node sequence that contains all nodes in the same hierarchy as the context node. This node sequence is then filtered by subsequent steps in the path expression. If the context item is not a node, a dynamic error is raised.

3.2.1 Steps

[25]   StepExpr   ::=   (ForwardStep |  ReverseStep |  PrimaryExpr) Predicates
[50]   ForwardStep   ::=   (ForwardAxis NodeTest) |  AbbreviatedForwardStep
[51]   ReverseStep   ::=   (ReverseAxis NodeTest) |  AbbreviatedReverseStep

A step generates a sequence of items and then filters the sequence by zero or more predicates. The value of the step consists of those items that satisfy the predicates. Predicates are described in 3.2.2 Predicates.

A step may consist of a primary expression (described in 3.1 Primary Expressions), a forward step, or a reverse step. A forward or reverse step always returns a sequence of nodes. A forward or reverse step might be thought of as beginning at the context node and navigating to those nodes that are reachable from the context node via a specified axis. Such a step has two parts: an axis, which defines the "direction of movement" for the step, and a node test, which specifies the node kind and/or name of the nodes to be selected by the step.

In the abbreviated syntax for a step, the axis can be omitted and other shorthand notations can be used as described in 3.2.4 Abbreviated Syntax.

The unabbreviated syntax for a forward or reverse step consists of the axis name and node test separated by a double colon. The result of the step consists of the nodes reachable from the context node via the specified axis that have the node kind and/or name specified by the node test. For example, the step child::para selects the para element children of the context node: child is the name of the axis, and para is the name of the element nodes to be selected on this axis. The available axes are described in 3.2.1.1 Axes. The available node tests are described in 3.2.1.2 Node Tests. Examples of steps are provided in 3.2.3 Unabbreviated Syntax and 3.2.4 Abbreviated Syntax.

3.2.1.1 Axes
[40]   ForwardAxis   ::=   <"child" "::">
|  <"descendant" "::">
|  <"attribute" "::">
|  <"self" "::">
|  <"descendant-or-self" "::">
[41]   ReverseAxis   ::=   <"parent" "::">

XQuery supports the following axes:

  • the child axis contains the children of the context node

  • the descendant axis contains the descendants of the context node; a descendant is a child or a child of a child and so on; thus the descendant axis never contains attribute or namespace nodes

  • the parent axis contains the parent of the context node, if there is one

  • the attribute axis contains the attributes of the context node; the axis will be empty unless the context node is an element

  • the self axis contains just the context node itself

  • the descendant-or-self axis contains the context node and the descendants of the context node

Axes can be categorized as forward axes and reverse axes. An axis that only ever contains the context node or nodes that are after the context node in document order is a forward axis. An axis that only ever contains the context node or nodes that are before the context node in document order is a reverse axis.

In XQuery, the parent axis is a reverse axis; all other axes are forward axes. Since the self axis always contains at most one node, it makes no difference whether it is a forward or reverse axis.

3.2.1.2 Node Tests

A node test is a condition that must be true for each node selected by a step. The condition may be based on the kind of the node (element, attribute, text, document, comment, processing instruction, or namespace) or on the name of the node.

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

Every axis has a principal node kind. If an axis can contain elements, then the principal node kind is element; otherwise, it is the kind of nodes that the axis can contain. Thus:

  • For the attribute axis, the principal node kind is attribute.

  • For the namespace axis, the principal node kind is namespace.

  • For all other axes, the principal node kind is element.

A node test that is a QName is true if and only if the kind of the node is the principal node kind and the expanded-name of the node is equal to the expanded-name specified by the QName. For example, child::para selects the para element children of the context node; if the context node has no para children, it selects an empty set of nodes. attribute::abc:href selects the attribute of the context node with the QName abc:href; if the context node has no such attribute, it selects an empty set of nodes.

A QName in a node test is expanded into an expanded-name using the in-scope namespaces in the expression context. An unprefixed QName used as a nametest has the namespaceURI associated with the default element namespace in the expression context. It is a static error if the QName has a prefix that does not correspond to any in-scope namespace.

A node test * is true for any node of the principal node kind. For example, child::* will select all element children of the context node, and attribute::* will select all attributes of the context node.

A node test can have the form NCName:*. In this case, the prefix is expanded in the same way as with a QName, using the context namespace declarations. It is a static error if there is no namespace declaration for the prefix in the expression context. The node test will be true for any node of the principal node kind whose expanded-name has the namespace URI to which the prefix expands, regardless of the local part of the name.

A node test can also have the form *:NCName. In this case, the node test is true for any node of the principal node kind whose local name matches the given NCName, regardless of its namespace.

The node test text() is true for any text node. For example, child::text() will select the text node children of the context node. Similarly, the node test comment() is true for any comment node, and the node test processing-instruction() is true for any processing instruction. The processing-instruction() test may have an argument that is a StringLiteral; in this case, it is true for any processing instruction whose target application is equal to the value of the StringLiteral.

A node test node() is true for any node whatsoever.

Note:

In order to be consistent with QName in XML, whitespace is not allowed in the Wildcard production. For instance "prefix:*" is allowed, but "prefix : *" is not allowed.

3.2.2 Predicates

[54]   Predicates   ::=   ("[" Expr "]")*

A predicate consists of an expression, called a predicate expression, enclosed in square brackets. A predicate serves to filter a sequence, retaining some items and discarding others. For each item in the sequence to be filtered, the predicate expression is evaluated using an inner focus derived from that item, as described in 2.1.2 Evaluation Context. The result of the predicate expression is coerced to a Boolean value, called the predicate truth value, as described below. Those items for which the predicate truth value is true are retained, and those for which the predicate truth value is false are discarded.

The predicate truth value is derived by applying the following rules, in order:

  1. If the value of the predicate expression is an empty sequence, the predicate truth value is false.

  2. If the value of the predicate expression is an atomic value of a numeric type, the predicate truth value is true if and only if the value of the predicate expression is equal to the context position.

  3. If the value of the predicate expression is an atomic value of type Boolean, the predicate truth value is equal to the value of the predicate expression.

  4. If the value of the predicate expression is a sequence that contains at least one node, the predicate truth value is true. The predicate truth value in this case does not depend on the content of the node(s).

  5. In any other case, a type exception is raised.

Here are some examples of steps that contain predicates:

  • This example selects the second "chapter" element that is a child of the context node:

    child::chapter[2]
  • This example selects all the descendants of the context node whose name is "toy" and whose "color" attribute has the value "red":

    descendant::toy[attribute::color = "red"]
  • This example selects all the "employee" children of the context node that have a "secretary" subelement:

    child::employee[secretary]

A predicate can also be used with a primary expression that is not a forward or reverse step, as illustrated in the following example:

  • List all the integers from 1 to 100 that are divisible by 5. (See 3.3.1 Constructing Sequences for an explanation of the to operator.)

    (1 to 100)[. mod 5 eq 0]

3.2.3 Unabbreviated Syntax

This section provides a number of examples of path expressions in which the axis is explicitly specified in each step. The syntax used in these examples is called the unabbreviated syntax. In many common cases, it is possible to write path expressions more concisely using an abbreviated syntax, as explained in 3.2.4 Abbreviated Syntax.

  • child::para selects the para element children of the context node

  • child::* selects all element children of the context node

  • child::text() selects all text node children of the context node

  • child::node() selects all the children of the context node, whatever their node type

  • attribute::name selects the name attribute of the context node

  • attribute::* selects all the attributes of the context node

  • descendant::para selects the para element descendants of the context node

  • descendant-or-self::para selects the para element descendants of the context node and, if the context node is a para element, the context node as well

  • self::para selects the context node if it is a para element, and otherwise selects nothing

  • child::chapter/descendant::para selects the para element descendants of the chapter element children of the context node

  • child::*/child::para selects all para grandchildren of the context node

  • / selects the root of the node hierarchy that contains the context node

  • /descendant::para selects all the para elements in the same document as the context node

  • /descendant::list/child::member selects all the member elements that have an list parent and that are in the same document as the context node

  • child::para[xf:position() = 1] selects the first para child of the context node

  • child::para[xf:position() = xf:last()] selects the last para child of the context node

  • child::para[xf:position() = xf:last()-1] selects the last but one para child of the context node

  • child::para[xf:position() > 1] selects all the para children of the context node other than the first para child of the context node

  • /descendant::figure[xf:position() = 42] selects the forty-second figure element in the document

  • /child::doc/child::chapter[xf:position() = 5]/child::section[xf:position() = 2]selects the second section of the fifth chapter of the doc document element

  • child::para[attribute::type="warning"]selects all para children of the context node that have a type attribute with value warning

  • child::para[attribute::type='warning'][xf:position() = 5]selects the fifth para child of the context node that has a type attribute with value warning

  • child::para[xf:position() = 5][attribute::type="warning"]selects the fifth para child of the context node if that child has a type attribute with value warning

  • child::chapter[child::title='Introduction']selects the chapter children of the context node that have one or more title children with string-value equal to Introduction

  • child::chapter[child::title] selects the chapter children of the context node that have one or more title children

  • child::*[self::chapter or self::appendix] selects the chapter and appendix children of the context node

  • child::*[self::chapter or self::appendix][xf:position() = xf:last()] selects the last chapter or appendix child of the context node

3.2.4 Abbreviated Syntax

[52]   AbbreviatedForwardStep   ::=   "." |  ("@" NameTest) |  NodeTest
[53]   AbbreviatedReverseStep   ::=   ".."

The abbreviated syntax permits the following abbreviations:

  1. The most important abbreviation is that child:: can be omitted from a step. In effect, child is the default axis. For example, a path expression section/para is short for child::section/child::para.

  2. There is also an abbreviation for attributes: attribute:: can be abbreviated by @. For example, a path expression para[@type="warning"] is short for child::para[attribute::type="warning"] and so selects para children with a type attribute with value equal to warning.

  3. // is short for /descendant-or-self::node()/. For example, //para is short for /descendant-or-self::node()/child::para and so will select any para element in the document (even a para element that is a document element will be selected by //para since the document element node is a child of the root node); div1//para is short for div1/descendant-or-self::node()/child::para and so will select all para descendants of div1 children.

    Note that the path expression //para[1] does not mean the same as the path expression /descendant::para[1]. The latter selects the first descendant para element; the former selects all descendant para elements that are the first para children of their parents.

  4. A step consisting of . returns the context item. This is particularly useful in conjunction with //. For example, the path expression .//para returns all para descendant elements of the context node.

  5. A step consisting of .. is short for parent::node(). For example, ../title is short for parent::node()/child::title and so will select the title children of the parent of the context node.

Here are some examples of path expressions that use the abbreviated syntax:

  • para selects the para element children of the context node

  • * selects all element children of the context node

  • text() selects all text node children of the context node

  • @name selects the name attribute of the context node

  • @* selects all the attributes of the context node

  • para[1] selects the first para child of the context node

  • para[xf:last()] selects the last para child of the context node

  • */para selects all para grandchildren of the context node

  • /doc/chapter[5]/section[2] selects the second section of the fifth chapter of the doc

  • chapter//para selects the para element descendants of the chapter element children of the context node

  • //para selects all the para descendants of the document root and thus selects all para elements in the same document as the context node

  • //list/member selects all the member elements in the same document as the context node that have an list parent

  • . selects the context node

  • .//para selects the para element descendants of the context node

  • .. selects the parent of the context node

  • ../@lang selects the lang attribute of the parent of the context node

  • para[@type="warning"] selects all para children of the context node that have a type attribute with value warning

  • para[@type="warning"][5] selects the fifth para child of the context node that has a typeattribute with value warning

  • para[5][@type="warning"] selects the fifth para child of the context node if that child has a type attribute with value warning

  • chapter[title="Introduction"] selects the chapter children of the context node that have one or more title children with string-value equal to Introduction

  • chapter[title] selects the chapter children of the context node that have one or more title children

  • employee[@secretary and @assistant] selects all the employee children of the context node that have both a secretary attribute and an assistant attribute

  • book/(chapter|appendix)/section selects every section element that has a parent that is either a chapter or an appendix element, that in turn is a child of a book element that is a child of the context node.

  • book/xf:id(publisher)/name returns the same result as xf:id(book/publisher)/name.

3.3 Sequence Expressions

XQuery supports operators to construct and combine sequences. A sequence is an ordered collection of zero or more items. An item may be an atomic value or a node. An item is identical to a sequence of length one 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).

3.3.1 Constructing Sequences

[4]   ExprSequence   ::=   Expr ("," Expr)*
[16]   RangeExpr   ::=   AdditiveExpr ( "to"  AdditiveExpr )*

One way to construct a sequence is by using the comma operator, which evaluates each of its operands and concatenates the resulting values, in order, into a single result sequence.

An ExprSequence is not an expression in its own right, and in general it must be enclosed in parentheses when used in a context where an expression is expected. There are, however, some contexts where parentheses are not required. These include the top-level QueryBody, and the contents of an enclosed expression in an element, attribute, or document constructor (where an ExprSequence appears between curly braces). Empty parentheses can be used to denote an empty sequence.

A sequence may contain duplicate values or nodes, but a sequence is never an item in another sequence. When a new sequence is created by concatenating two or more input sequences, the new sequence contains all the items of the input sequences and its length is the sum of the lengths of the input sequences.

Here are some examples of expressions that construct sequences:

  • This expression is a sequence of five integers:

    (10, 1, 2, 3, 4)
  • This expression constructs one sequence from the sequences 10, (1, 2), the empty sequence (), and (3, 4):

    (10, (1, 2), (), (3, 4))

    It evaluates to the sequence:

    10, 1, 2, 3, 4

  • This expression contains all salary children of the context node followed by all bonus children:

    (salary, bonus)
  • Assuming that $price is bound to the value 10.50, this expression:

    ($price, $price)

    evaluates to the sequence

    10.50, 10.50

A RangeExpr can be used to construct a sequence of consecutive integers. The to operator takes two operands, both of which have a required type of integer. A sequence is constructed containing the two integer operands and every integer between the two operands. If the first operand is less than the second, the sequence is in increasing order, otherwise it is in decreasing order.

  • This example uses a range expression as one operand in constructing a sequence:

    (10, 1 to 4)

    It evaluates to the sequence:

    10, 1, 2, 3, 4

  • This example constructs a sequence of length one:

    10 to 10

    It evaluates to a sequence consisting of the single integer 10.

3.3.2 Combining Sequences

[19]   UnionExpr   ::=   IntersectExceptExpr ( ("union" |  "|")  IntersectExceptExpr )*
[20]   IntersectExceptExpr   ::=   UnaryExpr ( ("intersect" |  "except")  UnaryExpr )*

XQuery provides several operators for combining sequences of nodes. The union and | operators are equivalent. They take two node sequences as operands and return a sequence containing all the nodes that occur in either of the operands. The intersect operator takes two node sequences as operands and returns a sequence containing all the nodes that occur in both operands. The except operator takes two node sequences as operands and returns a sequence containing all the nodes that occur in the first operand but not in the second operand. All of these operators return their result sequences in document order without duplicates based on node identity. If an operand of union, intersect, or except contains an item that is not a node, a dynamic error is raised.

Here are some examples of expressions that combine sequences. Assume the existence of three element nodes that we will refer to by symbolic names A, B, and C. Assume that $seq1 is bound to a sequence containing A and B, $seq2 is also bound to a sequence containing A and B, and $seq3 is bound to a sequence containing B and C. Then:

  • $seq1 union $seq1 evaluates to a sequence containing A and B.

  • $seq2 union $seq3 evaluates to a sequence containing A, B, and C.

  • $seq1 intersect $seq1 evaluates to a sequence containing A and B.

  • $seq2 intersect $seq3 evaluates to a sequence containing B only.

  • $seq1 except $seq2 evaluates to the empty sequence.

  • $seq2 except $seq3 evaluates to a sequence containing A only.

In addition to the sequence operators described here,[XQuery 1.0 and XPath 2.0 Functions and Operators] includes functions for indexed access to items or sub-sequences of a sequence, for indexed insertion or removal of items in a sequence, and for removing duplicate values or nodes from a sequence.

3.4 Arithmetic Expressions

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

[17]   AdditiveExpr   ::=   MultiplicativeExpr ( ("+" |  "-")  MultiplicativeExpr )*
[18]   MultiplicativeExpr   ::=   UnionExpr ( ("*" |  "div" |  "idiv" |  "mod")  UnionExpr )*
[21]   UnaryExpr   ::=   ("-" |  "+")* ValueExpr
[22]   ValueExpr   ::=   ValidateExpr |  CastExpr |  Constructor |  PathExpr

The binary subtraction operator must be preceded by whitespace if it could otherwise be interpreted as part of the previous token. For example, a-b will be interpreted as a name, but a - b will be interpreted as an arithmetic operation.

An arithmetic expression is evaluated by applying the following rules, in order, until an error is raised or a value is computed:

  1. Atomization is applied to each operand, resulting in a single atomic value or an empty sequence for each operand.

  2. If either operand is an empty sequence, the result of the operation is an empty sequence.

  3. If an operand has the type xs:anySimpleType, it is cast to xs:double. If the cast fails, a dynamic error is raised.

  4. If the two operands have different types, and these types can be promoted to a common type using the promotion rules in B.1 Type Promotion, the operands are both promoted to their least common type. For example, if the first operand is of type hatsize which is derived from xs:decimal, and the second operand is of type shoesize which is derived from xs:integer, then both operands are promoted to the type xs:decimal.

  5. If the operand type(s) are valid for the given operator, the operator is applied to the operand(s), resulting in an atomic value or a dynamic error (for example, an error might result from dividing by zero.) The combinations of atomic types that are accepted by the various arithmetic operators, and their respective result types, are listed in B.2 Operator Mapping. If the operand type(s) are not valid for the given operator, a type exception is raised.

XQuery supports two division operators named div and idiv. The div operator accepts operands of any numeric types. The result of the div operator is the least common type of its operands; however, if both operands are of type xs:integer, div returns a result of type xs:double. The idiv operator, on the other hand, requires its operands to be of type xs:integer and returns a result of type xs:integer, rounded toward zero.

Here are some examples of arithmetic expressions:

  • The first expression below returns -1.5E0, and the second expressions returns -1:

    -3 div 2
    -3 idiv 2
  • Subtraction of two date values results in a value of type xf:dayTimeDuration:

    $emp/hiredate - $emp/birthdate
  • This example illustrates the difference between a subtraction operator and a hyphen:

    $unit-price - $unit-discount
  • Unary operators have higher precedence than binary operators, subject of course to the use of parentheses:

    -($bellcost + $whistlecost)

3.5 Comparison Expressions

Comparison expressions allow two values to be compared. XQuery provides four kinds of comparison expressions, called value comparisons, general comparisons, node comparisons, and order comparisons.

[15]   ComparisonExpr   ::=   RangeExpr ( (ValueComp
|  GeneralComp
|  NodeComp
|  OrderComp)  RangeExpr )?
[33]   ValueComp   ::=   "eq" |  "ne" |  "lt" |  "le" |  "gt" |  "ge"
[32]   GeneralComp   ::=   "=" |  "!=" |  "<" |  "<=" |  ">" |  ">="
[34]   NodeComp   ::=   "is" |  "isnot"
[35]   OrderComp   ::=   "<<" |  ">>"

The "<" comparison operator must be followed by white space in order to distinguish it from a tag-open character. [Ed. Note: This rule may be relaxed, pending resolution of some general grammar issues.]

3.5.1 Value Comparisons

Value comparisons are intended for comparing single values. The result of a value comparison is defined by applying the following rules, in order:

  1. Atomization is applied to each operand, resulting in a single atomic value or an empty sequence for each operand.

  2. If either operand is an empty sequence, the result is an empty sequence.

  3. If either operand has the type xs:anySimpleType, that operand is cast to a required type, which is determined as follows:

    • If the type of the other operand is numeric, the required type is xs:double.

    • If the type of the other operand is xs:anySimpleType, the required type is xs:string.

    • Otherwise, the required type is the type of the other operand.

    If the cast fails, a dynamic error is raised.

  4. If the value comparison has two numeric operands of different types, one of the operands is promoted to the type of the other operand, following the promotion rules in B.1 Type Promotion. For example, a value of type xs:integer can be promoted to xs:decimal, and a value of type xs:decimal can be promoted to xs:double.

  5. The result of the comparison is true if the value of the first operand is (equal, not equal, less than, less than or equal, greater than, greater than or equal) to the value of the second operand; otherwise the result of the comparison is false. B.2 Operator Mapping describes which combinations of atomic types are comparable, and how comparisons are performed on values of various types. If the value of the first operand is not comparable with the value of the second operand, a type exception is raised.

Here are some examples of value comparisons:

  • The following comparison is true only if $book1 has a single author subelement and its value is "Kennedy":

    $book1/author eq "Kennedy"
  • The following comparison is true because the two constructed nodes have the same value, even though they have different identities:

    <a>5</a> eq <a>5</a>

Ed. Note: The current definitions of the value comparison operators are not transitive. The Working Group is discussing making value comparisons transitive by removing some implicit casts from value comparisons and adding them to general comparisons.

3.5.2 General Comparisons

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.

The general comparison A = B is true for sequences A and B if the value comparison a eq b is true for some item a in A and some item b in B. Otherwise, A = B is false.

Similarly:

  • A != B is true if and only if a ne b is true for some a in A and some b in B.

  • A < B is true if and only if a lt b is true for some a in A and some b in B.

  • A <= B is true if and only if a le b is true for some a in A and some b in B.

  • A > B is true if and only if a gt b is true for some a in A and some b in B.

  • A >= B is true if and only if a ge b is true for some a in A and some b in B.

Here is an example of a general comparison:

  • The following comparison is true if the value of any author subelement of $book1 is "Kennedy":

    $book1/author = "Kennedy"

3.5.3 Node Comparisons

The result of a node comparison is defined by applying the following rules, in order:

  1. Each operand must be either a single node or an empty sequence; otherwise a dynamic error is raised.

  2. If either operand is an empty sequence, the result of the comparison is an empty sequence.

  3. A comparison with the is operator is true if the two operands are nodes that have the same identity; otherwise it is false. A comparison with the isnot operator is true if the two operands are nodes that have different identities; otherwise it is false. See [XQuery 1.0 and XPath 2.0 Data Model] for a discussion of node identity.

Use of the is operator is illustrated below.

  • The following comparison is true only if the left and right sides each evaluate to exactly the same single node:

    //book[isbn="1558604820"] is //book[call="QA76.9 C3845"]
  • The following comparison is false because each constructed node has its own identity:

    <a>5</a> is <a>5</a>

3.5.4 Order Comparisons

The result of an order comparison is defined by applying the following rules, in order:

  1. Both operands must be either a single node or an empty sequence; otherwise a dynamic error is raised.

  2. If either operand is an empty sequence, the result of the comparison is an empty sequence.

  3. A comparison with the << operator returns true if the first operand node is earlier than the second operand node in document order; otherwise it returns false.

  4. A comparison with the >> operator returns true if the first operand node is later than the second operand node in document order; otherwise it returns false.

Here is an example of an order comparison:

  • The following comparison is true only if the node identified by the left side occurs before the node identified by the right side in document order:

    //purchase[parcel="28-451"] << //sale[parcel="33-870"]

3.6 Logical Expressions

A logical expression is either an and-expression or an or-expression. If a logical expression does not raise an error, its value is always one of the boolean values true or false.

[7]   OrExpr   ::=   AndExpr ( "or"  AndExpr )*
[8]   AndExpr   ::=   UnorderedExpr ( "and"  UnorderedExpr )*

The first step in evaluating a logical expression is to find the effective boolean value of each of its operands (see 2.4.3.2 Effective Boolean Value).

The value of an and-expression is determined by the effective boolean values (EBV's) of its operands. If an error is raised during computation of one of the effective boolean values, an and-expression may raise a dynamic error, as shown in the following table:

AND:EBV2 = trueEBV2 = falseerror in EBV2
EBV1 = truetruefalseerror
EBV1 = falsefalsefalsefalse or error
error in EBV1 errorfalse or errorerror

The value of an or-expression is determined by the effective boolean values (EBV's) of its operands. If an error is raised during computation of one of the effective boolean values, an or-expression may raise a dynamic error, as shown in the following table:

OR:EBV2 = trueEBV2 = falseerror in EBV2
EBV1 = truetruetruetrue or error
EBV1 = falsetruefalseerror
error in EBV1true or errorerrorerror

The order in which the operands of a logical expression are evaluated is implementation-dependent. The tables above are defined in such a way that an or-expression can return true if the first expression evaluated is true, and it can raise an error if evaluation of the first expression raises an error. Similarly, an and-expression can return false if the first expression evaluated is false, and it can raise an error if evaluation of the first expression raises an error. As a result of these rules, a logical expression is not deterministic in the presence of errors, as illustrated in the examples below.

Here are some examples of logical expressions:

  • The following expressions return true:

    1 eq 1 and 2 eq 2
    1 eq 1 or 2 eq 3
  • The following expression may return either false or raise a dynamic error:

    1 eq 2 and 3 idiv 0 = 1
  • The following expression may return either true or raise a dynamic error:

    1 eq 1 or 3 idiv 0 = 1
  • The following expression must raise a dynamic error:

    1 eq 1 and 3 idiv 0 = 1

In addition to and- and or-expressions, XQuery provides a function named not that takes a general sequence as parameter and returns a boolean value. The not function reduces its parameter to an effective boolean value. It then returns true if the effective boolean value of its parameter is false, and false if the effective boolean value of its parameter is true. If an error is encountered in finding the effective boolean value of its operand, not raises a dynamic error. The not function is described in [XQuery 1.0 and XPath 2.0 Functions and Operators].

3.7 Constructors

XQuery provides constructors that can create XML structures within a query. There are constructors for elements, attributes, CDATA sections, processing instructions, and comments. A special form of constructor called a computed constructor can be used to create an element or attribute with a computed name or to create a document node.

[31]   Constructor   ::=   ElementConstructor
|  XmlComment
|  XmlProcessingInstruction
|  CdataSection
|  ComputedDocumentConstructor
|  ComputedElementConstructor
|  ComputedAttributeConstructor
[70]   ElementConstructor   ::=   "<" QName AttributeList ("/>" |  (">" ElementContent* "</" QName S? ">"))
[77]   ElementContent   ::=   Char
|  "{{"
|  "}}"
|  ElementConstructor
|  EnclosedExpr
|  CdataSection
|  CharRef
|  PredefinedEntityRef
|  XmlComment
|  XmlProcessingInstruction
[78]   AttributeList   ::=   (S (QName S? "=" S? AttributeValue)?)*
[79]   AttributeValue   ::=   ('"' (EscapeQuot |  AttributeValueContent)* '"')
|  ("'" (EscapeApos |  AttributeValueContent)* "'")
[80]   AttributeValueContent   ::=   Char
|  CharRef
|  "{{"
|  "}}"
|  EnclosedExpr
|  PredefinedEntityRef
[81]   EnclosedExpr   ::=   "{" ExprSequence "}"

3.7.1 Element Constructors

An element constructor creates an XML element. If the name, attributes, and content of the element are all constants, the element constructor is based on standard XML notation. For example, the following expression creates a book element that contains attributes, subelements, and text:

<book isbn="isbn-0060229357">
    <title>Harold and the Purple Crayon</title>
    <author>
        <first>Crockett</first>
        <last>Johnson</last>
    </author>
</book>

In an element constructor, the name used in an end tag must match the name of the corresponding start tag.

In an element constructor, curly braces { } delimit enclosed expressions, distinguishing them from literal text. Enclosed expressions are evaluated and replaced by their value, whereas material outside curly braces is simply treated as literal text, as illustrated by the following example:

<example>
   <p> Here is a query. </p>
   <eg> $i//title </eg>
   <p> Here is the result of the above query. </p>
   <eg>{ $i//title }</eg>
</example>

The above query might generate the following result (whitespace has been added for readability to this result and other result examples in this document):

<example>
  <p> Here is a query. </p>
  <eg> $i//title </eg>
  <p> Here is the result of the above query. </p>
  <eg><title>Harold and the Purple Crayon</title></eg>
</example>

In an element constructor, an enclosed expression may evaluate to any sequence of nodes and/or atomic values. Attribute nodes occurring in this sequence become the attributes of the constructed element. The remainder of the sequence becomes the content of the constructed element.

An enclosed expression may also be used to compute the value of an attribute. If the enclosed expression returns a node, the typed value of the node is extracted and assigned to the attribute, as illustrated by the following example:

<book isbn="{$i/@booknum}" />

Since XQuery uses curly braces to denote enclosed expressions, some convention is needed to denote a curly brace used as an ordinary character. For this purpose, two adjacent curly brace characters occurring within the content of an element or attribute are interpreted by XQuery as a single curly brace character.

The names used in an element constructor may be qualified names that include namespace prefixes. Namespace prefixes can be bound to namespaces in the Query Prolog or in namespace declaration attributes. It is a static error to use a namespace prefix that has not been bound to a namespace.

A namespace declaration attribute serves to define a namespace prefix for use within the scope of an element constructor. A namespace declaration attribute always has the name xmlns or a QName with the prefix xmlns. If the value of a namespace declaration attribute is not a literal string, a static error is raised. Namespace declaration attributes are discussed further in 4.1 Namespace Declarations and [XML Names]. The following element constructor illustrates the use of namespace declaration attributes that define the namespace prefixes metric and english:

<box xmlns:metric = "http://example.org/metric/units"
     xmlns:english = "http://example.org/english/units">
  <height> <metric:meters>3</metric:meters> </height>
  <width> <english:feet>6</english:feet> </width>
  <depth> <english:inches>18</english:inches> </depth>
</box>

3.7.2 Computed Constructors

An alternative way to create nodes is by using a computed constructor. A computed constructor begins with a keyword that identifies the type of node to be created: element, attribute, or document. The keyword element or attribute is followed by the name of the node to be created (document nodes have no name). The name of an element or attribute may be specified either by a QName or by an enclosed expression that returns a QName. The final part of a computed constructor is an enclosed expression that generates the content of the node.

[72]   ComputedElementConstructor   ::=   (<"element" QName "{"> |  (<"element" "{"> Expr "}" "{")) ExprSequence? "}"
[73]   ComputedAttributeConstructor   ::=   (<"attribute" QName "{"> |  (<"attribute" "{"> Expr "}" "{")) ExprSequence? "}"
[71]   ComputedDocumentConstructor   ::=   <"document" "{"> ExprSequence "}"

The following example illustrates the use of computed element and attribute constructors in a simple case where the names of the constructed nodes are constants. This example generates exactly the same result as the first example in this section:

element book 
{
    attribute isbn { "isbn-0060229357" },
    element author 
    {
        element first { "Crockett" },
        element last { "Johnson" }
    }
} 

A computed element constructor might be used to make a modified copy of an existing element. For example, if the variable $e is bound to an element with numeric content, the following constructor might be used to create a new element with the same name as $e and with numeric content equal to twice the value of $e:

element
   {xf:node-name($e)}
   {2 * xf:data($e)}

One important purpose of computed element and attribute constructors is to allow the name of the constructed node to be computed. We will illustrate this feature by an expression that translates the name of an element from one language to another. Suppose that the variable $dict is bound to a sequence of entries in a translation dictionary. Here is an example entry:

<entry word="address">
   <variant lang="German">Adresse</variant>
   <variant lang="Italian">indirizzo</variant>
</entry> 

Suppose further that the variable $e is bound to the following element:

<address>123 Roosevelt Ave. Flushing, NY 11368</address>

Then the following expression generates a new element in which the name of $e has been translated into Italian and the content of $e (including its attributes, if any) has been preserved. The first enclosed expression after the element keyword generates the name of the element, and the second enclosed expression generates the content and attributes:

  element 
    {xf:expanded-QName("", 
       xf:data($dict/entry[word=name($e)]/variant[lang="Italian"]))}
    {$e/node()}

The result of this expression is as follows:

<indirizzo>123 Roosevelt Ave. Flushing, NY 11368</indirizzo>

An attribute generated by a computed element or attribute constructor may not be a namespace declaration attribute--that is, its name may not be xmlns or a QName with prefix xmlns; otherwise, a dynamic error is raised.

Additional examples of computed element constructors can be found in 5.4 Recursive Transformations.

A computed document constructor is useful when the result of a query is to be a document in its own right. In order to conform to the rules of [XML], the constructed document should contain exactly one top-level element node which serves as the root of the document (of course, this root element may in turn contain subelements.) The following example illustrates a query that returns an XML document whose root element is named author-list:

document
   {
      <author-list>
         document("bib.xml")//book/author
      </author-list>
   }

3.7.3 Whitespace in Constructors

As shown in the above examples, element and attribute constructors may contain literal characters interleaved with enclosed expressions and nested elements. In some cases, enclosed expressions and/or nested elements may be separated only by whitespace characters. For example, in the expression below, the end-tag </title> and the start-tag <author> are separated by a newline character and four space characters:

<book isbn="isbn-0060229357">
    <title>Harold and the Purple Crayon</title>
    <author>
        <first>Crockett</first>
        <last>Johnson</last>
    </author>
</book>

We will refer to whitespace characters that occur by themselves in the boundaries between tags and/or enclosed expressions, as in the above example, as boundary whitespace. The Query Prolog contains a declaration called xmlspace that controls whether boundary whitespace is preserved by element and attribute constructors. If xmlspace is not declared in the prolog or is declared as xmlspace = strip, boundary whitespace is not considered significant and is not preserved. On the other hand, if xmlspace = preserve is declared in the prolog, boundary whitespace is considered significant and is preserved.

  • Example:

    <a>  {"abc"}  </a>

    If xmlspace is not declared or is declared as xmlspace = strip, this example is equivalent to <a>abc</a>. However, if xmlspace = preserve is declared, this example is equivalent to <a>  abc  </a>.

  • Example:

    <a> z {"abc"}</a>

    Since the whitespace surrounding the z is not boundary whitespace, it is always preserved. This example is equivalent to <a> z abc  </a>.

For the purpose of the above rule, whitespace characters generated by character references such as &#x20; are not considered to be boundary whitespace, and are always preserved.

  • Example:

    <a>&#x20;{"abc"}</a>

    This example is equivalent to <a> abc</a>, regardless of the declaration of xmlspace.

It is important to remember that whitespace generated by an enclosed expression is never considered to be boundary whitespace, and is always preserved.

  • Example:

    <a>{"  "}</a>

    This example is equivalent to <a>  </a>, regardless of the declaration of xmlspace.

3.7.4 Data Model Representation

Element and attribute constructors can best be understood by examining how their values are represented in the Data Model. The descriptions in this section apply to both the computed and non-computed forms of element and attribute constructors. An XQuery implementation is free to use any implementation technique that produces the same result as the processing steps described in this section.

3.7.4.1 Constructed Element Nodes

The result of an element constructor is a new element node, with its own node identity. All the attribute and child nodes of the new element node are also new nodes with their own identities, even though they may be copies of existing nodes. The element node created by an element constructor always has a type annotation of xs:anyType. The element node may be given a more specific type by means of a validate expression.

Conceptually, an element constructor is processed by the following steps:

  1. The content of the element constructor is evaluated to produce a sequence of nodes, as follows:

    1. Each consecutive sequence of literal characters in the content of the element constructor evaluates to a single text node containing the characters. However, if the sequence consists entirely of boundary whitespace as defined in 3.7.3 Whitespace in Constructors and the Query Prolog does not specify xmlspace = preserve, then no text node is generated.

    2. Enclosed expressions are evaluated as follows: For each node returned by an enclosed expression, a new copy of the node is constructed, with a new node identity but retaining its original type annotation (if any). For each adjacent sequence of one or more atomic values returned by an enclosed expression, a new text node is constructed, containing the result of casting each atomic value to a string, with a single blank character inserted between adjacent values.

    3. Nested constructors are evaluated by recursively applying the rules in this section.

  2. Attribute nodes become attributes of the new element node.

  3. Adjacent text nodes are coalesced into a single text node by concatenating their contents, with no intervening blanks.

  4. The resulting sequence of nodes becomes the children of the new element node in the Data Model representation. Since the new element node has a type annotation of xs:anyType, its typed value is defined to be the same as its string value (the concatenated contents of all its text node descendants), as an instance of xs:anySimpleType. The value of the element may be given a more specific type by a cast expression, or by validating the element before extracting its typed value.

  • Example:

    <a>{1}</a>

    The constructed element node has one child, a text node containing the value "1".

  • Example:

    <a>{1, 2, 3}</a>

    The constructed element node has one child, a text node containing the value "1 2 3".

  • Example:

    <c>{1}{2}{3}</c>

    The constructed element node has one child, a text node containing the value "123".

  • Example:

    <b>{1, "2", "3"}</b>

    The constructed element node has one child, a text node containing the value "1 2 3".

  • Example:

    <fact>I saw 8 cats.</fact>

    The constructed element node has one child, a text node containing the value "I saw 8 cats.".

  • Example:

    <fact>I saw {5 + 3} cats.</fact>

    The constructed element node has one child, a text node containing the value "I saw 8 cats.".

  • Example:

    <fact>I saw <howmany>{5 + 3}</howmany> cats.</fact>

    The constructed element node has three children: a text node containing "I saw ", a child element node, and a text node containing " cats.". The child element node in turn has a single text node child containing the value "8".

  • Example:

    <cat>
       <breed>{$b}</breed>
       <color>{$c}</color>
    </cat>

    The constructed <cat> element node has two children: a constructed element node for the <breed> element, and a constructed element node for the <color> element. Whitespace surrounding the child elements has been stripped away by the element constructor (assuming that the Query Prolog did not specify xmlspace = preserve.)

  • Example:

    element
       {xf:node-name($e)}
       {$e/@*, 2 * xf:data($e)}

    This constructor creates a new element node that has the same name and attributes as the node bound to $e. The new node has one child text node whose value is computed by extracting the typed value of $e, multiplying it by 2, and casting the resulting value to a string. For example, if $e is bound by the expression let $e := <length units="inches">{5}</length>, then the result of the example expression is the element <length units="inches">10</length>.

Note that it is possible to construct an element that has an attribute named xsi:type. The existence of this attribute does not affect the type of the constructed node (but it may affect the validation process if the constructed node is later validated.)

3.7.4.2 Constructed Attribute Nodes

The result of an attribute constructor is a new attribute node, with its own node identity. Attribute nodes have no children. Attribute nodes created by an element or attribute constructor always have a type annotation of xs:anySimpleType. An attribute node may be given a more specific type by validating the element to which it is attached (if any).

Conceptually, an attribute constructor is processed by the following steps:

  1. The content of the attribute constructor is evaluated to produce a sequence of strings, as follows:

    1. Each consecutive sequence of literal characters in the content of the attribute constructor evaluates to a string containing the characters. However, if the sequence consists entirely of boundary whitespace as defined in 3.7.3 Whitespace in Constructors and the Query Prolog does not specify xmlspace = preserve, then the boundary whitespace is discarded.

    2. Enclosed expressions are evaluated as follows: Each node returned by an enclosed expression 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.

    3. Nested constructors are evaluated by recursively applying the rules in this section and replacing the resulting nodes with their string values.

  2. Adjacent strings are concatenated with no intervening blanks. The resulting string, as an instance of xs:anySimpleType, becomes the value of the attribute.

  • Example:

    <shoe size="{7}"/>

    The value of the size attribute is "7".

  • Example:

    <shoe size="7"/>

    The value of the size attribute is "7".

  • Example:

    <shoe size="As big as {$hat/@size}"/>

    The value of the size attribute is the string "As big as ", concatenated with the string value of the node denoted by the expression $hat/@size.

  • Example:

    attribute size {4 + 3}

    The value of the size attribute is "7".

3.7.5 Other Constructors and Comments

The syntax for a CDATA section constructor, a processing instruction constructor, or an XML comment constructor is the same as the syntax of the equivalent XML construct.

[74]   CdataSection   ::=   "<![CDATA[" Char* "]]>"
[75]   XmlProcessingInstruction   ::=   "<?" PITarget Char* "?>"
[76]   XmlComment   ::=   "<!--" Char* "-->"

The following examples illustrate constructors for processing instructions, comments, and CDATA sections.

<?format role="output" ?>
<!-- Tags are ignored in the following section -->
<![CDATA[ 
    <address>123 Roosevelt Ave. Flushing, NY 11368</address>
]]>

Ed. Note: The Data Model cannot currently represent a CDATA section (see Issue 293).

Note that an XML comment actually constructs an XML comment node. An XQuery comment (see 3.1.5 Comments) is simply a comment used in documenting a query, and is not evaluated. Consider the following example.

{-- This is an XQuery comment --}
<!-- This is an XML comment -->

The result of evaluating the above expression is as follows.

<!-- This is an XML comment -->

3.8 FLWR Expressions

XQuery provides a FLWR expression for iteration and for binding variables to intermediate results. This kind of expression is often useful for computing joins between two or more documents and for restructuring data. The name "FLWR", pronounced "flower", stands for the keywords for, let, where, and return, the four clauses found in a FLWR expression.

[10]   FLWRExpr   ::=   ((ForClause |  LetClause)+ WhereClause? "return")* QuantifiedExpr
[26]   ForClause   ::=   "for" TypeDeclaration? "$" VarName "in" Expr ("," TypeDeclaration? "$" VarName "in" Expr)*
[27]   LetClause   ::=   "let" TypeDeclaration? "$" VarName ":=" Expr ("," TypeDeclaration? "$" VarName ":=" Expr)*
[28]   WhereClause   ::=   "where" Expr
[63]   TypeDeclaration   ::=   SequenceType

The clauses of a FLWR Expression are interpreted as follows:

  1. A for clause associates one or more variables with expressions, creating tuples of variable bindings drawn from the Cartesian product of the sequences of values to which the expressions evaluate. The variable binding tuples are generated as an ordered sequence as described below.

    Each variable bound in a for clause may have an optional type declaration, which is a datatype declared using the syntax in 2.4.2 SequenceType. If the Static Typing Feature is implemented, and the static type of the expression bound to the variable, as inferred by the static type inference rules in [XQuery 1.0 Formal Semantics], is not a subtype of the datatype in the type declaration, a static type error is raised. If the Static Typing Feature is not implemented, and the dynamic type of a value bound to the variable does not match the declared type according to the rules for SequenceType Matching, a dynamic type error is raised.

  2. A let clause contains one or more variables, and binds each variable directly to the result of evaluating an expression. If for clauses are present, the variable bindings created by let clauses are added to the tuples generated by the for clauses. If there are no for clauses, the let clauses generate one tuple with all variable bindings.

    Each variable bound in a let clause may have an optional type declaration, which is a datatype declared using the syntax in 2.4.2 SequenceType. If the Static Typing Feature is implemented, and the static type of the expression bound to the variable, as inferred by the static type inference rules in [XQuery 1.0 Formal Semantics], is not a subtype of the datatype in the type declaration, a static type error is raised. If the Static Typing Feature is not implemented, and the dynamic type of a value bound to the variable does not match the declared type according to the rules for SequenceType Matching, a dynamic type error is raised.

  3. A where clause can be used as a filter for the tuples of variable bindings generated by the for and let clauses. The expression in the where clause, called the where-expression, is evaluated once for each of these tuples. If the effective boolean value of the where-expression is true, the tuple is retained and its variable bindings are used in an execution of the return clause. If the effective boolean value of the where-expression is false, the tuple is discarded. The effective boolean value of an expression is defined in 2.4.3.2 Effective Boolean Value.

  4. The return clause contains an expression that is used to construct the result of the FLWR expression. The return clause is invoked once for every tuple generated by the for and let clauses, after eliminating any tuples that do not satisfy the conditions of a where clause. The expression in the return clause is evaluated once for every invocation, and the result of the FLWR expression is an ordered sequence containing the results of these invocations.

A variable name may not be used before it is bound, nor may it be used in the expression to which it is bound. Any variable bound in a for or let clause is in scope until the end of the FLWR expression in which it is bound. If the variable name used in the binding was already bound in the current scope, the variable name refers to the newly bound variable until that variable goes out of scope. At this point, the variable name again refers to the variable of the prior binding.

Although for and let both bind variables, the manner in which variables are bound is quite different. In a let clause, each variable is bound directly to the result of an expression, as a whole. Consider the following query:

let $s := (<one/>, <two/>, <three/>)
return <out>{$s}</out>

The variable $s is bound to the result of the expression (<one/>, <two/>, <three/>). There are no for clauses, so the let clause generates one tuple that contains the binding of $s. The return clause is invoked for this tuple, creating the following output:

<out>
   <one/>
   <two/>
   <three/>
</out>

Now consider a similar query which contains a for clause instead of a let clause:

for $s in (<one/>, <two/>, <three/>)
return <out>{$s}</out>

The variable $s is associated with the expression (<one/>, <two/>, <three/>), from which the variable bindings of $s will be drawn. When only one expression is present, the Cartesian product is equivalent to the sequence of values returned by that expression. In this example, the variable $s is bound three times; first it is bound to <one/>, then to <two/>, and finally to <three/>. One tuple is generated for each of these variable bindings, and the return clause is invoked for each tuple, creating the following output:

<out>
   <one/>
</out>
<out>
   <two/>
</out>
<out>
   <three/>
</out>

A FLWR Expression may contain multiple for clauses. In this case, the tuples of variable bindings are drawn from the Cartesian product of the sequences returned by the expressions in all the for clauses. The ordering of the tuples is governed by the ordering of the sequences from which they were formed, working from left to right.

The following expression illustrates how tuples are generated from the Cartesian product of expressions in a for clause. This example contains type declarations that require the values bound to variables $i and $j to be of type xs:integer.

for xs:integer $i in (1, 2),
    xs:integer $j in (3, 4)
return
    <tuple>
      <i>{ $i }</i>
      <j>{ $j }</j>
    </tuple>

Here is the result of the above expression (the order is significant).

<tuple>
   <i>1</i>
   <j>3</j>
</tuple>
<tuple>
   <i>1</i>
   <j>4</j>
</tuple>
<tuple>
   <i>2</i>
   <j>3</j>
</tuple>
<tuple>
   <i>2</i>
   <j>4</j>
</tuple>

The following example inverts a document hierarchy to transform a bibliography into an author list. The bibliography is a list of books in which each book contains a list of authors. The example is based on the following input:

<bib>
  <book>
    <title>TCP/IP Illustrated</title>
    <author>
      W. Stevens
    </author>
    <publisher>Addison-Wesley</publisher>
  </book>
  <book>
    <title>Advanced Programming in the Unix environment</title>
    <author>
      W. Stevens
    </author>
    <publisher>Addison-Wesley</publisher>
  </book>
</bib>

The author list is a list of authors, where each author element contains the name of the author and a list of books written by that author. If an author has written more than one book, that author's name will occur more than once in the bibliography, but we want each author's name to occur only once in the author list. We will remove duplicates using the distinct-values function.

The distinct-values function takes a sequence of nodes or values as input, and returns a sequence in which duplicates have been removed by value. The order of this sequence is not significant. Two elements are considered to have duplicate values if their names, attributes, and normalized content are equal.

The following expression is used to transform the input bibliography into an author list:

<authlist>
 {
   let $input := document("bib.xml")
   for $a in distinct-values($input//author)
   return
     <author>
      {
        <name>
           { $a/text() }
        </name>,
        <books>
         {
           for $b in $input//book
           where $b/author = $a
           return $b/title 
         }
        </books>
      }
     </author>
 }
</authlist>

The result of the above expression is as follows:

<authlist>
  <author>
    <name>
      W. Stevens
    </name>
    <books>
      <title>TCP/IP Illustrated</title>
      <title>Advanced Programming in the Unix environment</title>
    </books>
  </author>
</authlist>

Note:

Query writers should use caution when combining FLWR expressions with path expressions. It is important to remember that path expressions always return their results in document order, whereas the order of the results of a FLWR expression are determined by the orderings of the sequences in the for clause.

3.9 Order-Related Expressions

XQuery provides two kinds of expressions that can affect the ordering of the items in a sequence: Sort Expressions and Unordered Expressions.

3.9.1 Sort Expressions

[6]   SortExpr   ::=   OrExpr ( "stable"? <"sort" "by" "("> SortSpecList ")" )*
[36]   SortSpecList   ::=   Expr SortModifier ("," SortSpecList)?
[37]   SortModifier   ::=   ("ascending" |  "descending")? (<"empty" "greatest"> |  <"empty" "least">)?

The value of the expression on the left side of the sort by keyword is called the input sequence. The items in the input sequence are called input items. The result of the sorting expression is called the output sequence. The output sequence contains all the input items, retaining their original identities (if any), but possibly in a different order.

The expressions on the right side of the sort by keyword are called ordering expressions. For each input item, the ordering expressions are evaluated with an inner focus derived from the input item, as described in 2.1.2 Evaluation Context. The input items are then reordered according to the values of their respective ordering expressions. If more than one ordering expression is specified, the leftmost ordering expression controls the primary sort, followed by the remaining ordering expressions from left to right. Each ordering expression can be followed by the keyword ascending or descending, which specifies the direction of the sort (ascending is the default). An ordering expression can also be followed by the optional keywords empty greatest or empty least, which specify the placement of input items whose ordering expression returns the empty sequence.

The process of evaluating and comparing the ordering expressions is based on the following rules:

  1. Atomization is applied to the result of each ordering expression, resulting in a single atomic value or an empty sequence for each operand ordering expression.

  2. If the result of an ordering expression has the type xs:anySimpleType (such as character data in a schemaless document), it is cast to the type xs:string.

  3. Each ordering expression must return values of the same type for all input items, and this type must be a (possibly optional) atomic type for which the gt operator is defined--otherwise, a dynamic error is raised.

  4. For the purpose of the following rule:

    1. For any ordering expression in which empty greatest is specified, an ordering value that is an empty sequence is treated as greater than any non-empty ordering value (that is ( ) gt x is true for any non-empty x.)

    2. For any ordering expression in which empty least is specified, an ordering value that is an empty sequence is treated as less than any non-empty ordering value (that is x gt ( ) is true for any non-empty x.)

    3. For any ordering expression in which neither empty greatest nor empty least is specified, an implementation may consistently treat an ordering value that is an empty sequence either as greater than any non-empty ordering value or as less than any non-empty ordering value.

  5. If V1 and V2 are the values of an ordering expression for input items I1 and I2 respectively, then:

    1. If the ordering expression is ascending, and if V2 gt V1 is true, then I1 precedes I2 in the output sequence.

    2. If the ordering expression is descending, and if V1 gt V2 is true, then I1 precedes I2 in the output sequence.

    3. If neither V1 gt V2 nor V2 gt V1 is true, and stable is specified, then the input order of I1 and I2 is preserved in output sequence.

    4. If neither V1 gt V2 nor V2 gt V1 is true, and stable is not specified, then the order of I1 and I2 in the output sequence is implementation-defined.

Here are some examples of ordering expressions:

  • This example lists all books with price greater than 100, in order by first author; within each group of books with the same first author, the books are ordered by title.

    //book[price > 100] sort by (author[1], title)
  • This example shows how the "." notation can be used to sort a sequence of atomic values (in this case, strings). The example returns all the authors of a given set of books, in alphabetic order.

    data(//book/author) sort by (.)
  • Ordering may be specified at multiple levels of a query result. The following example returns an alphabetic list of publishers. Within each publisher element it returns a list of books, each containing a title and a price, in descending order by price.

    <publisher_list>
       {for $p in distinct-values(document("bib.xml")//publisher)
        return
           <publisher>
              <name> {$p/text()} </name> 
              {for $b in document("bib.xml")//book[publisher = $p]
               return
                  <book>
                     {$b/title}
                     {$b/price}
                  </book> 
               sort by(price descending)
              }
           </publisher> 
        sort by(name)
       }
    </publisher_list>

Note:

Using a sort by expression may cause unexpected results when combined with a path expression. Consider the following example:

(employees sort by (salary))/name

One might expect that this query would return a list of employee names sorted in the order of their respective salaries. However, path expressions always return a node sequence in document order. Therefore, the result of this query is a list of employee names in document order. If the names are desired to be in salary order, the query should be rewritten as follows:

for $e in (employees sort by (salary)) return $e/name

3.9.2 Unordered Expressions

[9]   UnorderedExpr   ::=   "unordered"? FLWRExpr

The unordered keyword may be used as a prefix to any expression to indicate that its order is not significant. This feature allows an implementation to enhance performance by materializing a sequence of values in the most efficient way it can find.

The use of unordered is illustrated by the following example, which joins together two documents named parts.xml and suppliers.xml. The example returns the part numbers of red parts, paired with the supplier numbers of suppliers who supply these parts. If unordered were not specified, the resulting list of (part number, supplier number) pairs would be required to have an ordering that is controlled primarily by the document order of parts.xml and secondarily by the document order of suppliers.xml. However, this might not be the most efficient way to process the query if the ordering of the result is not important. An XQuery implementation might be able to process the query more efficiently by using an index to find the red parts, or by using suppliers.xml rather than parts.xml to control the primary ordering of the result. The unordered keyword gives the query evaluator freedom to make these kinds of optimizations.

unordered
for $p in document("parts.xml")//part[color = "Red"],
    $s in document("suppliers.xml")//supplier
where $p/suppno = $s/suppno
return
    <ps>
       { $p/partno, $s/suppno }
    </ps>

3.10 Conditional Expressions

XQuery supports a conditional expression based on the keywords if, then, and else.

[13]   IfExpr   ::=   (<"if" "("> Expr ")" "then" Expr "else")* InstanceofExpr

The expression following the if keyword is called the test expression, and the expressions following the then and else keywords are called the then-expression and else-expression, respectively.

The first step in processing a conditional expression is to find the effective boolean value of the test expression, as defined in 2.4.3.2 Effective Boolean Value.

The value of a conditional expression is defined as follows: If the effective boolean value of the test expression is true, the value of the then-expression is returned. If the effective boolean value of the test expression is false, the value of the else-expression is returned.

Conditional expressions have a special rule for propagating dynamic errors. If the effective value of the test expression is true, the conditional expression ignores (does not raise) any dynamic errors encountered in the else-expression. In this case, since the else-expression can have no observable effect, it need not be evaluated. Similarly, if the effective value of the test expression is false, the conditional expression ignores any dynamic errors encountered in the then-expression, and the then-expression need not be evaluated.

Here are some examples of conditional expressions:

  • In this example, the test expression is a comparison expression:

    if ($widget1/unit-cost < $widget2/unit-cost) 
      then $widget1
      else $widget2
  • In this example, the test expression tests for the existence of an attribute named discounted, independently of its value:

    if ($part/@discounted) 
      then $part/wholesale 
      else $part/retail

3.11 Quantified Expressions

Quantified expressions support existential and universal quantification. The value of a quantified expression is always true or false.

[11]   QuantifiedExpr   ::=   (("some" |  "every") TypeDeclaration? "$" VarName "in" Expr ("," TypeDeclaration? "$" VarName "in" Expr)* "satisfies")* TypeswitchExpr

A quantified expression begins with a quantifier, which is the keyword some or every, followed by one or more in-clauses that are used to bind variables, followed by the keyword satisfies and a test expression. Each in-clause associates a variable with an expression that returns a sequence of values. As in the case of a for-clause in a FLWR expression, the in-clauses generate tuples of variable bindings, using values drawn from the Cartesian product of the sequences returned by the binding expressions. Conceptually, the test expression is evaluated for each tuple of variable bindings. Results depend on the effective boolean values of the test expressions, as defined in 2.4.3.2 Effective Boolean Value. The value of the quantified expression is defined by the following rules:

  1. If the quantifier is some, the quantified expression is true if at least one evaluation of the test expression has the effective boolean value true; otherwise the quantified expression is false. This rule implies that, if the in-clauses generate zero binding tuples, the value of the quantified expression is false.

  2. If the quantifier is every, the quantified expression is true if every evaluation of the test expression has the effective boolean value true; otherwise the quantified expression is false. This rule implies that, if the in-clauses generate zero binding tuples, the value of the quantified expression is true.

Each variable bound in an in-clause of a quantified expression may have an optional type declaration, which is a datatype declared using the syntax in 2.4.2 SequenceType. If the Static Typing Feature is implemented, and the static type of the expression bound to the variable, as inferred by the static type inference rules in [XQuery 1.0 Formal Semantics], is not a subtype of the datatype in the type declaration, a static type error is raised. If the Static Typing Feature is not implemented, and the dynamic type of a value bound to the variable does not match the declared type according to the rules for SequenceType Matching, a dynamic type error is raised.

The order in which test expressions are evaluated for the various binding tuples is implementation-defined. If the quantifier is some, an implementation may return true as soon as it finds one binding tuple for which the test expression has an effective Boolean value of true, and it may raise a dynamic error as soon as it finds one binding tuple for which the test expression raises an error. Similarly, if the quantifier is every, an implementation may return false as soon as it finds one binding tuple for which the test expression has an effective Boolean value of false, and it may raise a dynamic error as soon as it finds one binding tuple for which the test expression raises an error. As a result of these rules, the value of a quantified expression is not deterministic in the presence of errors, as illustrated in the examples below.

Here are some examples of quantified expressions:

  • This expression is true if every part element has a discounted attribute (regardless of the values of these attributes):

    every $part in //part satisfies $part/@discounted
  • This expression is true if at least one employee element satisfies the given comparison expression:

    some $emp in //employee satisfies ($emp/bonus > 0.25 * $emp/salary)
  • In the following examples, each quantified expression evaluates its test expression over nine tuples of variable bindings, formed from the Cartesian product of the sequences (1, 2, 3) and (2, 3, 4). The expression beginning with some evaluates to true, and the expression beginning with every evaluates to false.

    some $x in (1, 2, 3), xs:integer $y in (2, 3, 4) 
         satisfies $x + $y = 4
    every $x in (1, 2, 3), xs:integer $y in (2, 3, 4) 
         satisfies $x + $y = 4
  • This quantified expression may either return true or raise a dynamic error, since its test expression returns true for one variable binding and raises an error for another:

    some $x in (1, 2, "cat") satisfies $x * 2 = 4
  • This quantified expression may either return false or raise a dynamic error, since its test expression returns false for one variable binding and raises an error for another:

    every $x in (1, 2, "cat") satisfies $x * 2 = 4
  • This quantified expression raises a static type error, since it contains a type declaration that is not satisfied by every item in the test expression. In this example, it is important to realize that the type declaration does not act as a filter on the items in the test expression, but instead acts as an assertion about the type of every item:

    some xs:integer $x in (1, 2, "cat") satisfies $x * 2 = 4

3.12 Expressions on SequenceTypes

In addition to their use in function parameters, SequenceTypes occur explicitly in instance of, typeswitch, cast, and treat expressions.

3.12.1 Instance Of

[14]   InstanceofExpr   ::=   ComparisonExpr ( <"instance" "of"> SequenceType )?

The boolean operator instance of returns true if the value of its first operand matches the type named in its second operand, according to the rules for SequenceType Matching; otherwise it returns false. For example:

  • 5 instance of xs:integer

    This example returns true because the given value is an instance of the given type.

  • <a>{5}</a> instance of xs:integer

    This example returns false because the given value is not an integer; instead, it is an element whose typed value is an integer.

  • <a>{5}</a> instance of element of type xs:integer

    This example returns false because a constructed but unvalidated element always has a type annotation of xs:anyType.

  • validate {<a>{5}</a>} instance of element of type xs:integer

    This example returns true if the validation process is successful and the schema definition for element a calls for content of type xs:integer.

  • validate {<a>{5}</a>} instance of element of type xs:integer

    This example returns true if the validation process is successful and the schema definition for element a calls for content of type xs:integer.

  • . instance of element

    This example returns true if the context item is an element node.

3.12.2 Typeswitch

[12]   TypeswitchExpr   ::=   (<"typeswitch" "("> Expr ")" CaseClause+ "default" ("$" VarName)? "return")* IfExpr
[38]   CaseClause   ::=   "case" SequenceType ("$" VarName)? "return" Expr

The typeswitch expression chooses one of several expressions to evaluate based on the dynamic type of an input value.

In a typeswitch expression, the typeswitch keyword is followed by an expression enclosed in parentheses, called the operand expression. This is the expression whose type is being tested. The remainder of the typeswitch expression consists of one or more case clauses and a default clause.

Each case clause specifies a SequenceType followed by an optional variable and a return expression. The effective case is the first case clause such that the value of the operand expression matches the SequenceType in the case clause, using the rules of SequenceType Matching. The value of the typeswitch expression is the value of the return expression in the effective case. If the value of the operand expression is not a value of any type named in a case clause, the value of the typeswitch expression is the value of the return expression in the default clause.

During evaluation of the return expression in a case or default clause, the variable named in the clause is bound to the value of the operand expression. If the return expression does not depend on the value of the operand expression, the variable may be omitted from the case or default clause.

The following example shows how a typeswitch expression might be used to process an expression in a way that depends on its dynamic type.

typeswitch($customer/billing-address)
   case element of type USAddress $a return $a/state
   case element of type CanadaAddress $a return $a/province
   case element of type JapanAddress $a return $a/prefecture
   default return "unknown"

3.12.3 Cast and Treat

[30]   CastExpr   ::=   (<"cast" "as"> |  <"treat" "as">) SequenceType ParenthesizedExpr

Occasionally it is necessary to convert a value to a specific datatype. For this purpose, XQuery provides a cast expression that creates a new value of a specific type based on an existing value. A cast expression takes two operands: an input expression and a SequenceType, called the target type. The cast expression first performs atomization on its input expression, resulting in a single atomic input value or the empty sequence. If the input value is the empty sequence, the cast expression returns an empty sequence. Otherwise, the cast expression creates a new instance of the target type that has the same lexical representation as the input value. The type of the input value is called the input type. cast is supported only for certain combinations of input type and target type, as listed below. For the purpose of these rules, we use the terms subtype and supertype in the following sense: if type B is derived from type A by restriction, then B is a subtype of A, and A is a supertype of B.

  • cast is supported for the combinations of input type and target type listed in [XQuery 1.0 and XPath 2.0 Functions and Operators]. For each of these combinations, both the input type and the target type are built-in schema types. For example, a value of type xs:string can be cast into the type xs:decimal.

    For every built-in type T that is defined in [XML Schema], a constructor function is provided whose name is the same as T and whose semantics are the same as a cast expression with target type T. For example, the function call xs:decimal($stringvalue) is equivalent to the expression cast as xs:decimal($stringvalue). If the argument to a constructor function is a literal, the result of the function may be computed statically, and an error encountered in this process may be reported as a static error. Constructor functions are described in more detail in [XQuery 1.0 and XPath 2.0 Functions and Operators].

  • cast is supported if the input type is a derived atomic type and the target type is a supertype of the input type. For example, if shoesize is derived by restriction from xs:integer, a value of type shoesize can be cast into the type xs:integer.

  • cast is supported if the target type is a derived atomic type and the input type is xs:string, xs:anySimpleType, or a supertype of the target type. If the input type is xs:string or xs:anySimpleType, its string value must be in the lexical space of the target type, and it is converted to the target type using the schema-defined rules for the target type. If the input type is a supertype of the target type, its value is mapped unchanged into the value space of the target type, and it is checked for conformance to all the facets of the target type (checking of a "pattern" facet may require generating a canonical lexical representation of the input value.)

For any combination of input type and target type that is not in the above list, a cast expression raises a static error.

If it is not possible to cast the input value into the value space of the target type, a dynamic error is raised. This includes the case when any facet of the target type is not satisfied. For example, cast as xs:integer($x) raises a dynamic error if the type of $x is xs:decimal and its value is 4.99 because this value cannot be represented with zero fractional digits.

In addition to cast, XQuery provides a type-checking expression called treat, which takes two operands: an expression and a SequenceType. Unlike cast, however, treat does not change the type or value of its operand. Instead, the purpose of treat is to ensure that an expression has an expected type at run-time.

The semantics of treat as type1 (expr2) are as follows:

  • During static analysis (if the Static Typing Feature is implemented):

    type1 must be a subtype of the static type of expr2, using the definition of subtype in [XQuery 1.0 Formal Semantics]--otherwise, a static type error is raised. The static type of the treat expression is type1. This enables the expression to be used as an argument of a function that requires a parameter of type1.

  • During expression evaluation (at "run-time"):

    If expr2 matches type1, using the SequenceType Matching rules in 2.4.2 SequenceType, the treat expression returns the value of expr2; otherwise, it raises a dynamic error. If the value of expr2 is returned, its identity is preserved. The treat expression ensures that the value of its expression operand conforms to the expected type at run-time.

  • Example:

    treat as element of type USAddress ($myaddress)

    The static type of $myaddress may be element of type Address, a less specific type than element of type USAddress. However, at run-time, the value of $myaddress must match the type element of type USAddress using SequenceType Matching rules; otherwise a dynamic error is raised.

3.13 Validate Expressions

[29]   ValidateExpr   ::=   "validate" SchemaContext? "{" Expr "}"

Ed. Note: Curly braces in this syntax may cause problems if this expression is embedded in XSLT--see Issue 267.)

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 of a validate expression may be any sequence of elements. Validation replaces element and attribute nodes with new nodes that have their own identity and that contain type annotations and defaults created by the validation process. If a hierarchy of nodes is validated by a validate expression, the hierarchical relationship among these nodes will be preserved among the nodes created by the validation process.

To allow locally declared elements and attributes to be validated, a schema context may optionally be specified. If no context is specified, all top-level names in the material to be validated are treated as global names.

The following example creates and validates a globally-declared person element:

   validate {
      <person>
        <name>
          <first>Elvira</first>
          <last>Fischbein</last>
        </name>
      </person>
   } 

The validate expression invokes the full schema validation process, except that identity constraints, as defined in section 3.11.4 of [XML Schema] Part 1, are not applied. All facets of simple types are checked, and default values are supplied as defined in the XML Schema specification.

Validating an expression is equivalent to the following steps:

  1. The value of the expression is converted from the Data Model to an XML Information Set (see [XML Infoset].) This step is equivalent to serializing the value of the expression in XML form and then parsing it to produce an Information Set.

  2. The Information Set produced in the previous step is validated according to the rules in [XML Schema], using the in-scope schema definitions. The result of this step is a Post-Schema Validation Infoset (PSVI). If the validation process is not successful, a dynamic type error is raised.

  3. The PSVI produced in the previous step is converted back into the Data Model by the mapping described in [XQuery 1.0 and XPath 2.0 Data Model]. If the Schema Import Feature is not implemented, this mapping maps each user-defined type onto its nearest predefined supertype, as described in 2.5.2 Conformance.

A validate expression may contain a SchemaContext that is used in validating locally declared elements and attributes. When a schema context is supplied, all element QNames are interpreted as they would be if found in that context in an XML document. If the schema context begins with a QName, the QName is interpreted as the name of a globally declared element; however, if the schema context begins with the keyword type, the first QName is interpreted as the name of a globally declared type. The steps inside the schema context trace a path relative to the globally declared element or type, as illustrated in the following examples, which are based on schemas defined in [XML Schema], Part 0:

  • Suppose that $x is bound to a shipTo element. Then validate in po:purchaseOrder {$x} validates the value of $x in the context of the global element declaration po:purchaseOrder.

  • Suppose that $y is bound to a productName element. Then validate in po:purchaseOrder/items/item {$y} validates the value of $y in the context of an item element, inside an items element, inside the global element declaration po:purchaseOrder.

  • Suppose that $z is bound to a zip element. Then validate in type po:USAddress {$z} validates the value of $z in the context of the global type declaration po:USAddress.

4 The Query Prolog

A query consists of a Query Prolog, followed by a Query Body.

The Query Prolog is a series of declarations and definitions that create the environment for query processing. The Query Prolog may contain namespace declarations, schema imports, an xmlspace declaration, a default collation, and some function definitions.

The Query Body consists of a sequence of expressions that define the result of the query.

[1]   Query   ::=   QueryProlog QueryBody
[2]   QueryProlog   ::=   (NamespaceDecl
|  XMLSpaceDecl
|  DefaultNamespaceDecl
|  DefaultCollationDecl
|  SchemaImport)* FunctionDefn*
[3]   QueryBody   ::=   ExprSequence?

4.1 Namespace Declarations

[84]   NamespaceDecl   ::=   <"declare" "namespace"> NCNameForPrefix "=" URLLiteral
[86]   DefaultNamespaceDecl   ::=   (<"default" "element"> |  <"default" "function">) "namespace" "=" URLLiteral

A Namespace Declaration defines a namespace prefix and associates it with a namespace URI, adding the (prefix, URI) pair to the set of in-scope namespaces. The namespace URI must be a valid URI, and may not be a zero-length string. The namespace declaration is in scope throughout the query in which it is declared, unless it is overridden by a namespace declaration attribute in an element constructor.

The following query illustrates a namespace declaration:

declare namespace foo = "http://example.org"
<foo:bar> Lentils </foo:bar> 

In the query result, the newly created node is in the namespace associated with the namespace URI http://example.org.

Multiple declarations of the same namespace prefix in the Query Prolog result in a static error.

{-- Error: multiple declarations of namespace 'xx' --}

declare namespace xx = "http://example.org/foo"
declare namespace xx = "http://example.org/bar"

//xx:bing

It is also a static error to use a QName with a namespace prefix that has not been declared, as in the following example:

{-- Error: use of undeclared namespace prefix --}
//xx:bing

In an element constructor, a namespace declaration attribute can be used to bind a prefix to a namespace, adding a (prefix, URI) pair to the set of in-scope namespaces. The binding of a prefix by a namespace declaration attribute is effective for the scope of the element in which it occurs, overriding any binding of the same prefix by a higher-level element or by the Query Prolog. If the value of a namespace declaration attribute is not a literal string, a static error is raised. In the data model, a namespace declaration is not an attribute, and it will not be retrieved by queries that return the attributes of an element. The following query illustrates a namespace declaration attribute that binds the prefix foo within the scope of a constructed element:

<foo:bar xmlns:foo="http://example.org">{ //foo:bing }</foo:bar>

When element or attribute names are compared, they are considered identical if the local part and namespace URI match. Namespace prefixes need not be identical for two names to match, as illustrated by the following example:

declare namespace xx = "http://example.org"

let $i := <foo:bar xmlns:foo = "http://example.org">
              <foo:bing> Lentils </foo:bing>
          </foo:bar>
return $i/xx:bing

Although the namespace prefixes xx and foo differ, both are bound to the namespace URI "http://example.org". Since xx:bing and foo:bing have the same local name and the same namespace URI, they match. The output of the above query is as follows.

<foo:bing> Lentils </foo:bing>

Default Namespace Declarations can be used to define namespace URIs to be associated with unprefixed names. The following kinds of default namespace declarations are supported:

  • default element namespace defines a namespace URI that is associated with unprefixed names of elements and types.

  • default function namespace defines a namespace URI that is associated with unprefixed names of functions.

If no default element namespace is in effect, unqualified names of elements and types are in no namespace. If no default function namespace is in effect, unqualified function names are considered to be in the namespace of XPath/XQuery functions, http://www.w3.org/2002/08/xquery-functions. Unqualified attribute names are never in a namespace, since XQuery provides no way to declare a default namespace for attributes.

XQuery has four predefined namespace prefixes that are present in the in-scope namespaces before each query is processed. These prefixes may be used without an explicit declaration. Their definitions may be overridden by namespace declarations in the Query Prolog or by namespace declaration attributes on constructed elements. The four predefined namespace prefixes are as follows:

  • xml = http://www.w3.org/XML/1998/namespace

  • xs = http://www.w3.org/2001/XMLSchema

  • xsd = http://www.w3.org/2001/XMLSchema-datatypes

  • xsi = http://www.w3.org/2001/XMLSchema-instance

4.2 Schema Imports

[89]   SchemaImport   ::=   <"import" "schema"> (StringLiteral |  SubNamespaceDecl |  DefaultNamespaceDecl) <"at" StringLiteral>?
[85]   SubNamespaceDecl   ::=   "namespace" NCNameForPrefix "=" URLLiteral

A Schema Import imports the element and attribute declarations and type definitions from a schema, mapping them into the Query Data Model using rules that will be specified in a future edition of [XQuery 1.0 Formal Semantics]. The URI in a schema import specifies the namespace to be imported, and optionally the location of the schema in which the namespace is defined. Importing a schema has no effect on the in-scope namespaces, since it does not associate a prefix with the namespace. When a schema is imported, the query generally accompanies the schema import with appropriate namespace or default namespace declarations to make it possible to refer to the names defined in the schema.

The following query searches for table elements in an XHTML document, after declaring the namespace and schema location for XHTML.

import schema "http://www.w3.org/1999/xhtml" 
            at "http://example.org/xhtml/xhtml.xsd"
declare namespace xhtml = "http://www.w3.org/1999/xhtml"

document("aspect.xhtml")//xhtml:table 

A shorthand notation is provided to allow a schema to be imported, and a namespace prefix to be bound to the target namespace of the schema, in a single step. This shorthand notation is illustrated by the following example, which is equivalent to the previous example:

import schema namespace xhtml="http://www.w3.org/1999/xhtml" 
            at "http://example.org/xhtml/xhtml.xsd"

document("aspect.xhtml")//xhtml:table 

The shorthand notation includes two URI's: the first one identifies a namespace and the second identifies a schema location. If the given namespace is not the target namespace of the schema at the given location, a static error is raised.

It is a static error to import two schemas that both define the same name in the same symbol space and in the same scope. For instance, a query may not import two schemas that provide global element declarations for two elements with the same expanded name.

4.3 Xmlspace Declaration

[82]   XMLSpaceDecl   ::=   <"declare" "xmlspace"> "=" ("preserve" |  "strip")

The xmlspace declaration in a Query Prolog controls whether boundary whitespace is preserved by element and attribute constructors during execution of the query, as described in 3.7.3 Whitespace in Constructors. If xmlspace = preserve is specified, boundary whitespace is preserved. If xmlspace = strip is specified or if no xmlspace declaration is present, boundary whitespace is stripped (deleted).

The following example illustrates an xmlspace declaration:

declare xmlspace = preserve

4.4 Default Collation

[83]   DefaultCollationDecl   ::=   <"default" "collation" "="> URLLiteral

A Query Prolog may declare a default collation, which is the name of the collation to be used by all functions and operators that require a collation if no other collation is specified. For example, the gt operator on strings is defined by a call to the xf:compare function, which takes an optional collation parameter. Since the gt operator does not specify a collation, the xf:compare function implements gt by using the default collation specified in the Query Prolog. The default collation is identified by a literal string containing a URI.

The following example illustrates a declaration of a default collation:

default collation = "http://example.org/languages/Icelandic"

If a Query Prolog specifies no default collation, the Unicode codepoint collation (http://www.w3.org/2002/08/query-operators/collation/codepoint) is used. If a Query Prolog specifies more than one default collation, or if the value specified for a default collation is not a string literal, a static error is raised.

4.5 Function Definitions

In addition to the built-in functions described in [XQuery 1.0 and XPath 2.0 Functions and Operators], XQuery allows users to define functions of their own. A function definition specifies the name of the function, the names and datatypes of the parameters, and the datatype of the result. All datatypes are specified using the syntax described in 2.4.2 SequenceType. A function definition also includes an expression called the function body that defines how the result of the function is computed from its parameters.

[87]   FunctionDefn   ::=   <"define" "function"> FuncName "(" ParamList? (")" |  (<")" "returns"> SequenceType)) EnclosedExpr
[88]   ParamList   ::=   Param ("," Param)*
[59]   Param   ::=   SequenceType? "$" VarName

The name of a function may be qualified with a namespace. The default namespace for functions is the namespace of the XML Query 1.0 and XPath 2.0 Functions and Operators, so these functions can be used without prefixes. The default namespace for functions may be changed by a default namespace declaration, as in this example:

default function namespace = "www.mylib.com" 

If a function parameter is declared using a name but no type, its default type is xs:anyType. If the returns clause is omitted from a function definition, its default return type is xs:anyType.

The following example illustrates the definition and use of a function that accepts a sequence of employee elements, summarizes them by department, and returns a sequence of dept elements.

  • Using a function, prepare a summary of employees that are located in Denver.

    define function summary(element employee* $emps) 
       returns element dept*
    {
       for $d in distinct-values($emps/deptno)
       let $e := $emps[deptno = $d]
       return
          <dept>
             {$d}
             <headcount> {count($e)} </headcount>
             <payroll> {sum($e/salary)} </payroll>
          </dept>
    }
    
    summary(document("acme_corp.xml")//employee[location = "Denver"])
    

The type of a function parameter or result may be a global type (declared as a top-level typename in some schema) or a local type (declared at some level of nesting inside a schema). Function parameters and results of local type can be declared with the help of a SchemaContext, as in the following example:

define function price(element product in type catalog $p)
  returns element USPrice in type catalog/product
{
   $p/USPrice
}

Rules for converting function arguments to their declared parameter types, and for converting the result of a function to its declared result type, are described in 3.1.4 Function Calls

A function may be defined recursively--that is, it may reference its own definition. Mutually recursive functions, whose bodies reference each other, are also allowed. The following example defines a recursive function that computes the maximum depth of an element hierarchy, and calls the function to find the maximum depth of a particular document. In its definition, the user-defined function depth calls the built-in functions empty and max.

  • Find the maximum depth of the document named partlist.xml.

    define function depth(element $e) returns xs:integer
    {
       {-- An empty element has depth 1 --}
       {-- Otherwise, add 1 to max depth of children --}
       if (empty($e/*)) then 1
       else max(for $c in $e/* return depth($c)) + 1
    }
    
    depth(document("partlist.xml"))
    

In XQuery 1.0, user-defined functions may not be overloaded. Only one function definition may have a given name. We consider function overloading to be a useful and important feature that deserves further study in future versions of XQuery. Although XQuery does not allow overloading of user-defined functions, some of the built-in functions in the XQuery core library are overloaded--for example, the string function of XPath can convert an instance of almost any type into a string.

Note:

If a future version of XQuery supports function overloading, an ambiguity may arise between a function that takes a node as parameter and a function with the same name that takes an atomic value as parameter (since a function call automatically extracts the atomic value of a node when necessary). The designers of such a future version of XQuery can avoid this ambiguity by writing suitable rules to govern function overloading. Nevertheless, users who are concerned about this possibility may choose to explicitly extract atomic values from nodes when calling functions that expect atomic values.

5 Example Applications

In previous sections, we have focused on explaining the meaning of the syntactic constructs of XQuery. This section contains examples of several important classes of queries that can be expressed using the syntax described in earlier sections. In some cases we describe functions introduced to support specific usage scenarios. In others, we show particular ways to combine operators that have already been introduced. The applications described here include joins across multiple data sources, grouping and aggregates, queries based on sequential relationships, and recursive transformations.

5.1 Joins

Joins, which combine data from multiple sources into a single result, are a very important type of query. In this section we will illustrate how several types of joins can be expressed in XQuery. We will base our examples on the following three documents:

  1. A document named parts.xml that contains many part elements; each part element in turn contains partno and description subelements.

  2. A document named suppliers.xml that contains many supplier elements; each supplier element in turn contains suppno and suppname subelements.

  3. A document named catalog.xml that contains information about the relationships between suppliers and parts. The catalog document contains many item elements, each of which in turn contains partno, suppno, and price subelements.

A conventional ("inner") join returns information from two or more related sources, as illustrated by the following example, which combines information from three documents. The example generates a "descriptive catalog" derived from the catalog document, but containing part descriptions instead of part numbers and supplier names instead of supplier numbers. The new catalog is ordered alphabetically by part description and secondarily by supplier name.

<descriptive-catalog>
   { 
     for $i in document("catalog.xml")//item,
         $p in document("parts.xml")//part[partno = $i/partno],
         $s in document("suppliers.xml")//supplier[suppno = $i/suppno]
     return
        <item>
           {
           $p/description,
           $s/suppname,
           $i/price
           }
        </item>
     sort by(description, suppname)
   }
</descriptive-catalog>

The previous query returns information only about parts that have suppliers and suppliers that have parts. An outer join is a join that preserves information from one or more of the participating sources, including elements that have no matching element in the other source. For example, a left outer join between suppliers and parts might return information about suppliers that have no matching parts.

The following query demonstrates a left outer join. It returns names of all the suppliers in alphabetic order, including those that supply no parts. In the result, each supplier element contains the descriptions of all the parts it supplies, in alphabetic order.

for $s in document("suppliers.xml")//supplier
return
   <supplier>
      { 
        $s/suppname,
        for $i in document("catalog.xml")//item
                 [suppno = $s/suppno],
            $p in document("parts.xml")//part
                 [partno = $i/pno]
        return $p/description 
        sort by(.)
      }
   </supplier>
sort by(suppname)

The previous query preserves information about suppliers that supply no parts. Another type of join, called a full outer join, might be used to preserve information about both suppliers that supply no parts and parts that have no supplier. The result of a full outer join can be structured in any of several ways. The following query generates a list of supplier elements, each containing nested part elements for the parts that it supplies (if any), followed by a list of part elements for the parts that have no supplier. This might be thought of as a "supplier-centered" full outer join. Other forms of outer join queries are also possible.

<master-list>
 {
    for $s in document("suppliers.xml")//supplier
    return
        <supplier>
           { 
             $s/suppname,
             for $i in document("catalog.xml")//item
                     [suppno = $s/suppno],
                 $p in document("parts.xml")//part
                     [partno = $i/partno]
             return
                <part>
                   {
                     $p/description,
                     $i/price
                   }
                </part> 
             sort by (description)
           }
        </supplier> 
    sort by (suppname) 
    ,
    {-- parts that have no supplier --}
    <orphan-parts>
       { for $p in document("parts.xml")//part
         where empty(document("catalog.xml")//item
               [partno = $p/partno] )
         return $p/description 
         sort by (.)
       }
    </orphan-parts>
 }
</master-list>

The previous query uses an element constructor to enclose its output inside a master-list element. The concatenation operator (",") is used to combine the two main parts of the query. The result is an ordered sequence of supplier elements followed by an orphan-parts element that contains descriptions of all the parts that have no supplier.

5.2 Grouping

Many queries involve forming data into groups and applying some aggregation function such as count or avg to each group. The following example shows how such a query might be expressed in XQuery, using the catalog document defined in the previous section.

This query finds the part number and average price for parts that have at least 3 suppliers.

for $pn in distinct-values(document("catalog.xml")//partno)
let $i := document("catalog.xml")//item[partno = $pn]
where count($i) >= 3
return 
   <well-supplied-item>
      {$pn}
      <avgprice> {avg($i/price)} </avgprice>
   </well-supplied-item> 
sort by(partno)

The distinct-values function in this query eliminates duplicate part numbers from the set of all part numbers in the catalog document. The result of distinct-values is a sequence in which order is not significant.

Note that $pn, bound by a for clause, represents an individual part number, whereas $i, bound by a let clause, represents a set of items which serves as argument to the aggregate functions count($i) and avg($i/price). The query uses an element constructor to enclose each part number and average price in a containing element called well-supplied-item.

5.3 Queries on Sequence

XQuery uses the << and >> operators to compare nodes based on document order. Although these operators are quite simple, they can be used to express complex queries for XML documents in which sequence is meaningful. The first two queries in this section involve a surgical report that contains procedure, incision, instrument, action, and anesthesia elements.

The following query returns all the action elements that occur between the first and second incision elements inside the first procedure. The original document order among these nodes is preserved in the result of the query.

let $proc := input()//procedure[1]
for $i in $proc//action
where $i >> ($proc//incision)[1]
   and $i << ($proc//incision)[2]
return $i

It is worth noting here that document order is defined in such a way that a node is considered to precede its descendants in document order. In the surgical report, an action is never part of an incision, but an instrument is. Since the >> operator is based on document order, the predicate $i >> ($proc//incision)[1] is true for any instrument element that is a descendant of the first incision element in the first procedure.

For some queries, it may be helpful to define a function that can test whether a node precedes another node without being its ancestor. The following function returns true if its first operand precedes its second operand but is not an ancestor of its second operand; otherwise it returns false:

define function precedes(node $a, node $b) returns boolean
{
     $a << $b
       and
     empty($a//node() intersect $b)
}

Similarly, a follows function could be written:

define function follows(node $a, node $b) returns boolean
{
     $a >> $b
       and
     empty($b//node() intersect $a)
}

Using the precedes function, we can now write a function that finds instrument elements between the first two incisions, excluding from the query result any instrument that is a descendant of the first incision:

let $proc := input()//procedure[1]
for $i in $proc//instrument
where precedes(($proc//incision)[1], $i)
   and precedes($i, ($proc//incision)[2])
return $i

The following query reports incisions for which no prior anesthesia was recorded in the surgical report. Since an anesthesia is never part of an incision, we can use << instead of the less-efficient precedes function:

for $p in input()//procedure
where some $i in $proc//incision satisfies
         empty($proc//anesthesia[. << $i])
return $p

In some documents, particular sequences of elements may indicate a logical hierarchy. This is most commonly true of HTML. The following query returns the introduction of an XHTML document, wrapping it in a div element. In this example, we assume that an h2 element containing the text "Introduction" marks the beginning of the introduction, and the introduction continues until the next h2 or h1 element, or the end of the document, whichever comes first.

let $intro := input()//h2[text()="Introduction"],
       $next-h := input()//(h1|h2)[. >> $intro][1]
return
     <div>
       {
         $intro,
         if (empty($next-h))
           then //node()[. >> $intro]
           else //node()[. >> $intro and . << $next-h]
       }
     </div>

Note that the above query makes explicit the hierarchy that was implicit in the original document. In this example, we assume that the h2 element containing the text "Introduction" has no subelements.

5.4 Recursive Transformations

Occasionally it is necessary to scan over a hierarchy of elements, applying some transformation at each level of the hierarchy. In XQuery this can be accomplished by defining a recursive function. In this section we will present two examples of such recursive functions.

Suppose that we need to compute a table of contents for a given document by scanning over the document, retaining only elements named section or title, and preserving the hierarchical relationships among these elements. For each section, we retain subelements named section or title; but for each title, we retain the full content of the element. This might be accomplished by the following recursive function:

define function sections-and-titles(node $n) returns node?
   {
   if (xf:local-name($n) = "section")
   then element
          { xf:local-name($n) }
          { for $c in $n/* return sections-and-titles($c) }
   else if (xf:local-name($n) = "title")
   then $n
   else ( )
   }

The "skeleton" of a given document, containing only its sections and titles, can then be obtained by invoking the sections-and-titles function on the root node of the document, as follows:

sections-and-titles(document("cookbook.xml"))

As another example of a recursive transform, suppose that we wish to scan over a document, transforming every attribute named color to an element named color, and every element named size to an attribute named size. This can be accomplished by the following recursive function:

define function swizzle(node $n) returns node
   {
   if ($n instance of attribute and local-name($n) = "color")
   then element color { string($n) }
   else if ($n instance of element and local-name($n) = "size")
   then attribute size { string($n) }
   else if ($n instance of element)
   then element
          { local-name($n) }
          { for $c in $n/* return swizzle($c) }
   else $n
   }

The transformation can be applied to a whole document by invoking the swizzle function on the root node of the document, as follows:

swizzle(document("plans.xml"))

A XQuery Grammar

A.1 Lexical structure

A character is an atomic unit of text as specified by ISO/IEC 10646 [ISO/IEC 10646] (see also [ISO/IEC 10646-2000]). Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646, as long as these characters are legal XML characters as defined in the [XML] recommendation.

A lexical pattern is a rule that describes how a sequence of characters can match a grammar unit. A lexeme is the smallest meaningful unit in the grammar that has syntactic interpretation. A token is a symbol that matches lexemes, and is the output of the lexical analyzer. A token symbol is the symbolic name given to that token. A single token may be composed of one or more lexemes. If there is more than one lexeme, they may be separated by whitespace or punctuation. For instance, the token AxisDescendantOrSelf has two lexemes, "descendant-or-self" and "::".

PatternLexeme(s)Token Names (for example)
"or""or"Or
"=""="Equals
(Prefix ':')? LocalPart"p:foo"QName
<"descendant-or-self" "::">"descendant-or-self"AxisDescendantOrSelf
"::"

When patterns are simple string matches, the strings are embedded directly into the BNF. In other cases, token symbols are used when the pattern is a more complex regular expression (the major cases of these are NCName, QName, and Number and String literals). It is up to an implementation to decide on the exact tokenization strategy, which may be different depending on the parser construction. For instance, an implementation may decide that a token named For is composed of only "for", or may decide that it is composed of ("for" "("). In the first case the implementation may decide to use lexical lookahead to distinguish the "for" lexeme from a QName that has the lexeme "for". In the second case, the implementation may decide to combine the two lexemes into a single "long" token. In either case, the end grammatical result will be the same. Lexemes that must be described by lexical lookahead are delimited with the tokens that it must look ahead to, in order to be recoginized, by "<" and ">".

This grammar implies lexical states, which are lexical constraints on the tokenization process based on grammatical positioning. The exact structure of these states is left to the implementation, but the normative rules for calculating these states are given in the A.1.2 Lexical Rules section.

When tokenizing, the longest possible match that is valid in the current lexical state is prefered .

For readability, Whitespace may be used in most expressions even though not explicitly allowed by the grammar: Whitespace may be freely added between lexemes, except a few cases where whitespace is needed to disambiguate the token. For instance, in XML, "-" is a valid character in an element or attribute name. When used as an operator after the characters of a name, it must be separated from the name, e.g. by using whitespace or parentheses.

For XMLQuery, Whitespace is not freely allowed in the Constructor productions, but is specified specifically in the grammar, in order to be more consistent with XML. Lexically, these states are as follows: START_TAG, ELEMENT_CONTENT, END_TAG, XML_COMMENT, PROCESSING_INSTRUCTION, CDATA_SECTION, QUOT_ATTRIBUTE_CONTENT, and APOS_ATTRIBUTE_CONTENT.

All keywords are case sensitive.

Ed. Note: Since currently ExprComments are specified at the lexical level, I leave it as an editorial issue as to how to describe this, or whether to constrain where ExprComments are allowed so they can be described by the BNF. (I would be in favor of this. -sb)

A.1.1 Syntactic Constructs

A.1.2 Lexical Rules

As discussed above, there are various strategies that can be used by an implementation to disambiguate token symbol choices. Among the choices are lexical look-ahead and look-behind, a two-pass lexical evaluation, and a single recursive descent lexical evaluation and parse. This specification does not dictate what strategy to use. However, this section does describe normative rules with which these decisions must conform to.

The lexical contexts and transitions between lexical contexts is described in terms of a series of states and transitions between those states. An implementation need not follow this approach in implementing lexer rules, but does need to conform to the results. For instance, instead of using a state automata, an implementation might use lexecal look-behind, or might use a full context-free-grammar parse, or it might make extensive use of parser lookahead (and use a more ambiguous token strategy).

The tables below define the complete lexical rules for XQuery. Each table corresponds to a lexical state in which the tokens listed are recognized only in that state. When a given token is recognized in the given state, the transition to the next state is given. In some cases, a transition will "push" the current state or a specific state onto an abstract stack, and will later restore that state by a "pop" when another lexical event occurs. [Ed. Note: pushParenState(...), popParenState(...), and resetParenStateOrSwitch(...) are left unexplained for now. Briefly, these are used to maintain the ITEMTYPE state within a function definition in XQuery, since it is hard to distinguish lexically between a function call and a function definition. Since the lexical state mechanism is shared between XPath and XQuery, these are used in the XPath tables also, even though they are not strictly needed.]

The lexical states have in many cases close connection to the parser productions. However, just because a token is recognized in a certain lexical state, does not mean it will be legal in the parser state.

The #ANY State

This state is for patterns that can be recognized in any state.

PatternTransition To State
WhitespaceChar
Nmstart
Nmchar
Digits
HexDigits
(maintain current state)

The DEFAULT State

This state is for patterns that occur at the beginning of an expression.

PatternTransition To State
"?"
"["
"+"
"-"
";"
"empty"
"stable"
<"at" StringLiteral>
DEFAULT
"{"
DEFAULT
pushState(DEFAULT)
<"attribute" QName "{">
<"element" QName "{">
<"element" "{">
<"document" "{">
<"attribute" "{">
DEFAULT
pushState(DEFAULT)
<"type" QName>
"validate"
"*"
<NCName ":" "*">
<"*" ":" NCName>
"."
".."
StringLiteral
OPERATOR
<"of" "type">
"/"
"//"
<"child" "::">
<"descendant" "::">
<"parent" "::">
<"attribute" "::">
<"self" "::">
<"descendant-or-self" "::">
"@"
QNAME
<"default" "collation" "=">
<"declare" "namespace">
NAMESPACEDECL
<"default" "element">
<"default" "function">
<"import" "schema">
NAMESPACEKEYWORD
<"declare" "xmlspace">
XMLSPACE_DECL
"for"
"let"
"some"
"every"
<"cast" "as">
<"treat" "as">
ITEMTYPE
<"define" "function">
FUNCDEF
"$"
VARNAME

START_TAG
pushState(OPERATOR)
"<!--"
XML_COMMENT
pushState()
"<?"
PROCESSING_INSTRUCTION
pushState()
"<![CDATA["
CDATA_SECTION
pushState()
S
(maintain state)
","
resetParenStateOrSwitch(DEFAULT)
"("
pushParenState(DEFAULT)
<"text" "(">
<"comment" "(">
<"node" "(">
<"processing-instruction" "(">
pushParenState(DEFAULT)
<QName "(">
<"if" "(">
pushParenState(DEFAULT)
")"
popParenState(OPERATOR)
"unordered"
(maintain state)
<")" "returns">
popParenState(ITEMTYPE)
"}"
popState

The OPERATOR State

This state is for patterns that are defined for operators.

PatternTransition To State
"/"
"//"
"div"
"idiv"
"mod"
"and"
"or"
"*"
"return"
"then"
"else"
"to"
"union"
"intersect"
"except"
"="
"is"
"!="
"isnot"
"<="
">="
"<"
">"
"|"
"<<"
">>"
"eq"
"ne"
"gt"
"ge"
"lt"
"le"
"in"
"where"
"satisfies"
":="
"?"
"["
"+"
"-"
";"
<"at" StringLiteral>
"item"
"node"
"document"
"comment"
"text"
DEFAULT
"{"
DEFAULT
pushState(DEFAULT)
<NCName ":" "*">
<"*" ":" NCName>
"."
".."
"ascending"
"descending"
<"empty" "greatest">
<"empty" "least">
StringLiteral
"default"
OPERATOR
<"of" "type">
QNAME
<"default" "collation" "=">
<"declare" "namespace">
NAMESPACEDECL
<"default" "element">
<"default" "function">
<"import" "schema">
NAMESPACEKEYWORD
<"declare" "xmlspace">
XMLSPACE_DECL
"for"
"let"
"some"
"every"
<"instance" "of">
"case"
ITEMTYPE
<"define" "function">
FUNCDEF
"$"
VARNAME
S
(maintain state)
<"sort" "by" "(">
pushParenState(DEFAULT)
","
resetParenStateOrSwitch(DEFAULT)
"("
pushParenState(DEFAULT)
")"
popParenState(OPERATOR)
"unordered"
(maintain state)
<")" "returns">
popParenState(ITEMTYPE)
"}"
popState

The QNAME State

When a qualified name is expected, and it is required to remove ambiguity from patterns that look like keywords, this state is used.

PatternTransition To State
";"
DEFAULT
"*"
<NCName ":" "*">
<"*" ":" NCName>
"."
".."
OPERATOR
"/"
"//"
<"child" "::">
<"descendant" "::">
<"parent" "::">
<"attribute" "::">
<"self" "::">
<"descendant-or-self" "::">
"@"
QNAME
"$"
VARNAME
S
(maintain state)
"("
pushParenState(DEFAULT)
<"text" "(">
<"comment" "(">
<"node" "(">
<"processing-instruction" "(">
pushParenState(DEFAULT)
")"
popParenState(OPERATOR)
<")" "returns">
popParenState(ITEMTYPE)

The NAMESPACEDECL State

This state occurs inside of a namespace declaration, and is needed to recognize a NCName that is to be used as the prefix, as opposed to allowing a QName to occur. (Otherwise, the difference between NCName and QName are ambiguous.)

PatternTransition To State
URLLiteral
DEFAULT
"="
NCNameForPrefix
NAMESPACEDECL
S
(maintain state)

The NAMESPACEKEYWORD State

This state occurs at places where the keyword "namespace" is expected, which would otherwise be ambiguous compared to a QName. QNames can not occur in this state.

PatternTransition To State
StringLiteral
OPERATOR
"namespace"
NAMESPACEDECL
S
(maintain state)

The XMLSPACE_DECL State

This state occurs at places where the keywords "preserve" and "strip" is expected to support "declare xmlspace". QNames can not occur in this state.

PatternTransition To State
"preserve"
"strip"
DEFAULT
"="
(maintain state)

The ITEMTYPE State

This state distinguishes tokens that can occur only inside the ItemType production.

PatternTransition To State
"attribute"
"element"
"node"
"document"
"comment"
"text"
"processing-instruction"
"item"
"untyped"
<"atomic" "value">
AtomicType
DEFAULT
<NCName ":" "*">
<"*" ":" NCName>
"."
".."
OPERATOR
"$"
VARNAME
S
(maintain state)
")"
popParenState(OPERATOR)
<")" "returns">
popParenState(ITEMTYPE)

The FUNCDEF State

This state is defined to recognise a FuncName, which then transitions to an ITEMTYPE state after the opening left bracket, in order to recognize SequenceType productions.

PatternTransition To State
S
(maintain state)
FuncName
(maintain state)
"("
pushParenState(ITEMTYPE)

The VARNAME State

This state differentiates variable names from qualified names. This allows only the pattern of a QName to be recognized when otherwise ambiguities could occur.

PatternTransition To State
VarName
OPERATOR

The START_TAG State

This state allows attributes in the native XML syntax, and marks the beginning of an element construction. Element constructors also push the current state, popping it at the conclusion of an end tag. In the START_TAG state, the string ">" is recognized as a token which is associated with the transition to the original state.

PatternTransition To State

DEFAULT
pushState()
">"
ELEMENT_CONTENT
'"'
QUOT_ATTRIBUTE_CONTENT
"'"
APOS_ATTRIBUTE_CONTENT
S
(maintain state)
QName
(maintain state)
"="
(maintain state)
"/>"
popState

The ELEMENT_CONTENT State

This state allows XML-like content, without these characters being misinterpreted as expressions. The character "{" marks a transition to the DEFAULT state, i.e. the start of an embedded expression, and the "}" character pops back to the ELEMENT_CONTENT state. To allow curly braces to be used as character content, a double left or right curly brace is interpreted as a single curly brace character. The string "</" is interpreted as the beginning of an end tag, which is associated with a transition to the END_TAG state.

PatternTransition To State

DEFAULT
pushState()
"<"
START_TAG
pushState()
"</"
END_TAG
"<!--"
XML_COMMENT
pushState()
"<?"
PROCESSING_INSTRUCTION
pushState()
"<![CDATA["
CDATA_SECTION
pushState()
"]]>"
popState
PredefinedEntityRef
CharRef
(maintain state)
"{{"
"}}"
(maintain state)
Char
(maintain state)

The END_TAG State

When the end tag is terminated, the state is popped to the state that was pushed at the start of the corresponding start tag.

PatternTransition To State

DEFAULT
pushState()
S
(maintain state)
QName
(maintain state)
">"
popState

The XML_COMMENT State

The "<--" token marks the beginning of an XML Comment, and the "-->" token marks the end. This allows no special interpretation of other characters in this state.

PatternTransition To State
Char
(maintain state)
"-->"
popState

The PROCESSING_INSTRUCTION State

In this state, only lexemes that are legal in a processing instruction name are recognized.

PatternTransition To State
PITarget
PROCESSING_INSTRUCTION_CONTENT

The PROCESSING_INSTRUCTION_CONTENT State

In this state, only characters are that are legal in processing instruction content are recognized.

PatternTransition To State
Char
(maintain state)
"?>"
popState

The CDATA_SECTION State

In this state, only lexemes that are legal in a CDATA section are recognized.

PatternTransition To State
"]]>"
popState
Char
(maintain state)

The QUOT_ATTRIBUTE_CONTENT State

This state allows content legal for attributes. The character "{" marks a transition to the DEFAULT state, i.e. the start of an embedded expression, and the "}" character pops back to the original state. To allow curly braces to be used as character content, a double left or right curly brace is interpreted as a single curly brace character. This state is the same as QUOT_ATTRIBUTE_CONTENT, except that apostrophes are allowed without escaping, and an unescaped quote marks the end of the state.

PatternTransition To State

DEFAULT
pushState()
'"'
START_TAG
EscapeQuot
QUOT_ATTRIBUTE_CONTENT
PredefinedEntityRef
CharRef
(maintain state)
"{{"
"}}"
(maintain state)
Char
(maintain state)

The APOS_ATTRIBUTE_CONTENT State

This state is the same as QUOT_ATTRIBUTE_CONTENT, except that quotes are allowed, and an unescaped apostrophe marks the end of the state.

PatternTransition To State

DEFAULT
pushState()
"'"
START_TAG
EscapeApos
APOS_ATTRIBUTE_CONTENT
PredefinedEntityRef
CharRef
(maintain state)
"{{"
"}}"
(maintain state)
Char
(maintain state)

A.2 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.

Note:

Note that the Semicolon character is reserved for future use.

NON-TERMINALS

[1]   Query   ::=   QueryProlog QueryBody
[2]   QueryProlog   ::=   (NamespaceDecl
|  XMLSpaceDecl
|  DefaultNamespaceDecl
|  DefaultCollationDecl
|  SchemaImport)* FunctionDefn*
[3]   QueryBody   ::=   ExprSequence?
[4]   ExprSequence   ::=   Expr ("," Expr)*
[5]   Expr   ::=   SortExpr
[6]   SortExpr   ::=   OrExpr ( "stable"? <"sort" "by" "("> SortSpecList ")" )*
[7]   OrExpr   ::=   AndExpr ( "or"  AndExpr )*
[8]   AndExpr   ::=   UnorderedExpr ( "and"  UnorderedExpr )*
[9]   UnorderedExpr   ::=   "unordered"? FLWRExpr
[10]   FLWRExpr   ::=   ((ForClause |  LetClause)+ WhereClause? "return")* QuantifiedExpr
[11]   QuantifiedExpr   ::=   (("some" |  "every") TypeDeclaration? "$" VarName "in" Expr ("," TypeDeclaration? "$" VarName "in" Expr)* "satisfies")* TypeswitchExpr
[12]   TypeswitchExpr   ::=   (<"typeswitch" "("> Expr ")" CaseClause+ "default" ("$" VarName)? "return")* IfExpr
[13]   IfExpr   ::=   (<"if" "("> Expr ")" "then" Expr "else")* InstanceofExpr
[14]   InstanceofExpr   ::=   ComparisonExpr ( <"instance" "of"> SequenceType )?
[15]   ComparisonExpr   ::=   RangeExpr ( (ValueComp
|  GeneralComp
|  NodeComp
|  OrderComp)  RangeExpr )?
[16]   RangeExpr   ::=   AdditiveExpr ( "to"  AdditiveExpr )*
[17]   AdditiveExpr   ::=   MultiplicativeExpr ( ("+" |  "-")  MultiplicativeExpr )*
[18]   MultiplicativeExpr   ::=   UnionExpr ( ("*" |  "div" |  "idiv" |  "mod")  UnionExpr )*
[19]   UnionExpr   ::=   IntersectExceptExpr ( ("union" |  "|")  IntersectExceptExpr )*
[20]   IntersectExceptExpr   ::=   UnaryExpr ( ("intersect" |  "except")  UnaryExpr )*
[21]   UnaryExpr   ::=   ("-" |  "+")* ValueExpr
[22]   ValueExpr   ::=   ValidateExpr |  CastExpr |  Constructor |  PathExpr
[23]   PathExpr   ::=   ("/" RelativePathExpr?) |  ("//" RelativePathExpr) |  RelativePathExpr
[24]   RelativePathExpr   ::=   StepExpr (("/" |  "//") StepExpr)*
[25]   StepExpr   ::=   (ForwardStep |  ReverseStep |  PrimaryExpr) Predicates
[26]   ForClause   ::=   "for" TypeDeclaration? "$" VarName "in" Expr ("," TypeDeclaration? "$" VarName "in" Expr)*
[27]   LetClause   ::=   "let" TypeDeclaration? "$" VarName ":=" Expr ("," TypeDeclaration? "$" VarName ":=" Expr)*
[28]   WhereClause   ::=   "where" Expr
[29]   ValidateExpr   ::=   "validate" SchemaContext? "{" Expr "}"
[30]   CastExpr   ::=   (<"cast" "as"> |  <"treat" "as">) SequenceType ParenthesizedExpr
[31]   Constructor   ::=   ElementConstructor
|  XmlComment
|  XmlProcessingInstruction
|  CdataSection
|  ComputedDocumentConstructor
|  ComputedElementConstructor
|  ComputedAttributeConstructor
[32]   GeneralComp   ::=   "=" |  "!=" |  "<" |  "<=" |  ">" |  ">="
[33]   ValueComp   ::=   "eq" |  "ne" |  "lt" |  "le" |  "gt" |  "ge"
[34]   NodeComp   ::=   "is" |  "isnot"
[35]   OrderComp   ::=   "<<" |  ">>"
[36]   SortSpecList   ::=   Expr SortModifier ("," SortSpecList)?
[37]   SortModifier   ::=   ("ascending" |  "descending")? (<"empty" "greatest"> |  <"empty" "least">)?
[38]   CaseClause   ::=   "case" SequenceType ("$" VarName)? "return" Expr
[39]   PrimaryExpr   ::=   Literal |  FunctionCall |  ("$" VarName) |  ParenthesizedExpr
[40]   ForwardAxis   ::=   <"child" "::">
|  <"descendant" "::">
|  <"attribute" "::">
|  <"self" "::">
|  <"descendant-or-self" "::">
[41]   ReverseAxis   ::=   <"parent" "::">
[42]   NodeTest   ::=   KindTest |  NameTest
[43]   NameTest   ::=   QName |  Wildcard
[44]   Wildcard   ::=   "*" |  <NCName ":" "*"> |  <"*" ":" NCName>
[45]   KindTest   ::=   ProcessingInstructionTest
|  CommentTest
|  TextTest
|  AnyKindTest
[46]   ProcessingInstructionTest   ::=   <"processing-instruction" "("> StringLiteral? ")"
[47]   CommentTest   ::=   <"comment" "("> ")"
[48]   TextTest   ::=   <"text" "("> ")"
[49]   AnyKindTest   ::=   <"node" "("> ")"
[50]   ForwardStep   ::=   (ForwardAxis NodeTest) |  AbbreviatedForwardStep
[51]   ReverseStep   ::=   (ReverseAxis NodeTest) |  AbbreviatedReverseStep
[52]   AbbreviatedForwardStep   ::=   "." |  ("@" NameTest) |  NodeTest
[53]   AbbreviatedReverseStep   ::=   ".."
[54]   Predicates   ::=   ("[" Expr "]")*
[55]   NumericLiteral   ::=   IntegerLiteral |  DecimalLiteral |  DoubleLiteral
[56]   Literal   ::=   NumericLiteral |  StringLiteral
[57]   ParenthesizedExpr   ::=   "(" ExprSequence? ")"
[58]   FunctionCall   ::=   <QName "("> (Expr ("," Expr)*)? ")"
[59]   Param   ::=   SequenceType? "$" VarName
[60]   SchemaContext   ::=   "in" SchemaGlobalContext ("/" SchemaContextStep)*
[61]   SchemaGlobalContext   ::=   QName |  <"type" QName>
[62]   SchemaContextStep   ::=   QName
[63]   TypeDeclaration   ::=   SequenceType
[64]   SequenceType   ::=   (ItemType OccurrenceIndicator) |  "empty"
[65]   ItemType   ::=   (("element" |  "attribute") ElemOrAttrType?)
|  "node"
|  "processing-instruction"
|  "comment"
|  "text"
|  "document"
|  "item"
|  AtomicType
|  "untyped"
|  <"atomic" "value">
[66]   ElemOrAttrType   ::=   (QName (SchemaType |  SchemaContext?)) |  SchemaType
[67]   SchemaType   ::=   <"of" "type"> QName
[68]   AtomicType   ::=   QName
[69]   OccurrenceIndicator   ::=   ("*" |  "*" |  "+" |  "?")?
[70]   ElementConstructor   ::=   "<" QName AttributeList ("/>" |  (">" ElementContent* "</" QName S? ">"))
[71]   ComputedDocumentConstructor   ::=   <"document" "{"> ExprSequence "}"
[72]   ComputedElementConstructor   ::=   (<"element" QName "{"> |  (<"element" "{"> Expr "}" "{")) ExprSequence? "}"
[73]   ComputedAttributeConstructor   ::=   (<"attribute" QName "{"> |  (<"attribute" "{"> Expr "}" "{")) ExprSequence? "}"
[74]   CdataSection   ::=   "<![CDATA[" Char* "]]>"
[75]   XmlProcessingInstruction   ::=   "<?" PITarget Char* "?>"
[76]   XmlComment   ::=   "<!--" Char* "-->"
[77]   ElementContent   ::=   Char
|  "{{"
|  "}}"
|  ElementConstructor
|  EnclosedExpr
|  CdataSection
|  CharRef
|  PredefinedEntityRef
|  XmlComment
|  XmlProcessingInstruction
[78]   AttributeList   ::=   (S (QName S? "=" S? AttributeValue)?)*
[79]   AttributeValue   ::=   ('"' (EscapeQuot |  AttributeValueContent)* '"')
|  ("'" (EscapeApos |  AttributeValueContent)* "'")
[80]   AttributeValueContent   ::=   Char
|  CharRef
|  "{{"
|  "}}"
|  EnclosedExpr
|  PredefinedEntityRef
[81]   EnclosedExpr   ::=   "{" ExprSequence "}"
[82]   XMLSpaceDecl   ::=   <"declare" "xmlspace"> "=" ("preserve" |  "strip")
[83]   DefaultCollationDecl   ::=   <"default" "collation" "="> URLLiteral
[84]   NamespaceDecl   ::=   <"declare" "namespace"> NCNameForPrefix "=" URLLiteral
[85]   SubNamespaceDecl   ::=   "namespace" NCNameForPrefix "=" URLLiteral
[86]   DefaultNamespaceDecl   ::=   (<"default" "element"> |  <"default" "function">) "namespace" "=" URLLiteral
[87]   FunctionDefn   ::=   <"define" "function"> FuncName "(" ParamList? (")" |  (<")" "returns"> SequenceType)) EnclosedExpr
[88]   ParamList   ::=   Param ("," Param)*
[89]   SchemaImport   ::=   <"import" "schema"> (StringLiteral |  SubNamespaceDecl |  DefaultNamespaceDecl) <"at" StringLiteral>?

A.3 Reserved Words

The following is a list of reserved words for XQuery:

  • for

  • let

  • some

  • every

  • unordered

  • validate

Ed. Note: This version of the grammar has made an attempt to reduce the number of reserved words.

Ed. Note: See issue xpath-issue-reserved-words.

A.4 Precedence Order

In all cases the grammar defines built-in precedence. In the cases where a number of statements are a choice at the same production level, the expressions are always evaluated from left to right.

B Type Promotion and Operator Mapping

B.1 Type Promotion

Under certain circumstances, an atomic value can be promoted from one type to another. The promotion rules listed below are used in basic type conversions (see 2.4.3 Type Conversions) and during processing of arithmetic expressions (see 3.4 Arithmetic Expressions) and value comparisons (see 3.5.1 Value Comparisons). The rules may be applied transitively. For example, since xs:integer is promotable to xs:decimal and xs:decimal is promotable to xs:float, it follows that xs:integer is promotable to xs:float, without necessarily passing through the intermediate xs:decimal type.

The following type promotions are permitted:

  1. A value of type xs:decimal can be promoted to the type xs:float. The result is the xs:float value that is closest to the original value.

  2. A value of type xs:float can be promoted to the type xs:double. The result is the xs:double value that is the same as the original value.

  3. A value of a derived type can be promoted to its base type. The result is the base-type value that is the same as the original value. As an example of this rule, a value of the derived type xs:integer can be promoted to its base type xs:decimal.

B.2 Operator Mapping

The tables in this section list the combinations of datatypes for which the various operators of XQuery are defined. For each valid combination of datatypes, the table indicates the function(s) that are used to implement the operator and the datatype of the result. Definitions of the functions can be found in [XQuery 1.0 and XPath 2.0 Functions and Operators]. Note that in some cases the function does not implement the full semantics of the given operator. For a complete description of each operator (including its behavior for empty sequences or sequences of length greater than one), see the descriptive material in the main part of this document.

In the following tables, the term numeric refers to the types xs:integer, xs:decimal, xs:float, and xs:double. When the result type of an operator is listed as numeric, it means "same as the highest type of any input operand, in promotion order." For example, when invoked with operands of type xs:integer and xs:float, the binary + operator returns a result of type xs:float.

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

Binary Operators
OperatorType(A)Type(B)FunctionResult type
A + Bnumericnumericop:numeric-add(A, B)numeric
A + Bxs:datexf:yearMonthDurationop:add-yearMonthDuration-to-date(A, B)xs:date
A + Bxf:yearMonthDurationxs:dateop:add-yearMonthDuration-to-date(B, A)xs:date
A + Bxs:datexf:dayTimeDurationop:add-dayTimeDuration-to-date(A, B)xs:date
A + Bxf:dayTimeDurationxs:dateop:add-dayTimeDuration-to-date(B, A)xs:date
A + Bxs:timexf:dayTimeDurationop:add-dayTimeDuration-to-time(A, B)xs:time
A + Bxf:dayTimeDurationxs:timeop:add-dayTimeDuration-to-time(B, A)xs:time
A + Bxs:datetimexf:yearMonthDurationop:add-yearMonthDuration-to-dateTime(A, B)xs:dateTime
A + Bxf:yearMonthDurationxs:datetimeop:add-yearMonthDuration-to-dateTime(B, A)xs:dateTime
A + Bxs:datetimexf:dayTimeDurationop:add-dayTimeDuration-to-dateTime(A, B)xs:dateTime
A + Bxf:dayTimeDurationxs:datetimeop:add-dayTimeDuration-to-dateTime(B, A)xs:dateTime
A + Bxf:yearMonthDurationxf:yearMonthDurationop:add-yearMonthDurations(A, B)xf:yearMonthDuration
A + Bxf:dayTimeDurationxf:dayTimeDurationop:add-dayTimeDurations(A, B)xf:dayTimeDuration
A - Bnumericnumericop:numeric-subtract(A, B)numeric
A - Bxs:datexs:datexf:subtract-dates(A, B)xf:dayTimeDuration
A - Bxs:datexf:yearMonthDurationop:subtract-yearMonthDuration-from-date(A, B)xs:date
A - Bxs:datexf:dayTimeDurationop:subtract-dayTimeDuration-from-date(A, B)xs:date
A - Bxs:timexs:timexf:subtract-times(A, B)xf:dayTimeDuration
A - Bxs:timexf:dayTimeDurationop:subtract-dayTimeDuration-from-time(A, B)xs:time
A - Bxs:datetimexs:datetimexf:get-dayTimeDuration-from-dateTimes(A, B)xf:dayTimeDuration
A - Bxs:datetimexf:yearMonthDurationop:subtract-yearMonthDuration-from-dateTime(A, B)xs:dateTime
A - Bxs:datetimexf:dayTimeDurationop:subtract-dayTimeDuration-from-dateTime(A, B)xs:dateTime
A - Bxf:yearMonthDurationxf:yearMonthDurationop:subtract-yearMonthDurations(A, B)xf:yearMonthDuration
A - Bxf:dayTimeDurationxf:dayTimeDurationop:subtract-dayTimeDurations(A, B)xf:dayTimeDuration
A * Bnumericnumericop:numeric-multiply(A, B)numeric
A * Bxf:yearMonthDurationxs:decimalop:multiply-yearMonthDuration(A, B)xf:yearMonthDuration
A * Bxs:decimalxf:yearMonthDurationop:multiply-yearMonthDuration(B, A)xf:yearMonthDuration
A * Bxf:dayTimeDurationxs:decimalop:multiply-dayTimeDuration(A, B)xf:dayTimeDuration
A * Bxs:decimalxf:dayTimeDurationop:multiply-dayTimeDuration(B, A)xf:dayTimeDuration
A idiv Bxs:integerxs:integerop:integer-div(A, B)xs:integer
A div Bnumericnumericop:numeric-divide(A, B)numeric; but xs:double if both operands are xs:integer
A div Bxf:yearMonthDurationxs:decimalop:divide-yearMonthDuration(A, B)xf:yearMonthDuration
A div Bxf:dayTimeDurationxs:decimalop:divide-dayTimeDuration(A, B)xf:dayTimeDuration
A mod Bnumericnumericop:numeric-mod(A, B)numeric
A eq Bnumericnumericop:numeric-equal(A, B)xs:boolean
A eq Bxs:booleanxs:booleanop:boolean-equal(A, B)xs:boolean
A eq Bxs:stringxs:stringop:numeric-equal(xf:compare(A, B), 1)xs:boolean
A eq Bxs:datexs:dateop:date-equal(A, B)xs:boolean
A eq Bxs:timexs:timeop:time-equal(A, B)xs:boolean
A eq Bxs:dateTimexs:dateTimeop:datetime-equal(A, B)xs:boolean
A eq Bxf:yearMonthDurationxf:yearMonthDurationop:yearMonthDuration-equal(A, B)xs:boolean
A eq Bxf:dayTimeDurationxf:dayTimeDurationop:dayTimeDuration-equal(A, B)xs:boolean
A eq BGregorianGregorianop:gYear-equal(A, B) etc.xs:boolean
A eq Bxs:hexBinaryxs:hexBinaryop:hex-binary-equal(A, B)xs:boolean
A eq Bxs:base64Binaryxs:base64Binaryop:base64-binary-equal(A, B)xs:boolean
A eq Bxs:anyURIxs:anyURIop:anyURI-equal(A, B)xs:boolean
A eq Bxs:QNamexs:QNameop:QName-equal(A, B)xs:boolean
A eq Bxs:NOTATIONxs:NOTATIONop:NOTATION-equal(A, B)xs:boolean
A ne Bnumericnumericxf:not(op:numeric-equal(A, B))xs:boolean
A ne Bxs:booleanxs:booleanxf:not(op:boolean-equal(A, B))xs:boolean
A ne Bxs:stringxs:stringxf:not(op:numeric-equal(xf:compare(A, B), 1))xs:boolean
A ne Bxs:datexs:datexf:not(op:date-equal(A, B))xs:boolean
A ne Bxs:timexs:timexf:not(op:time-equal(A, B))xs:boolean
A ne Bxs:dateTimexs:dateTimexf:not(op:datetime-equal(A, B))xs:boolean
A ne Bxf:yearMonthDurationxf:yearMonthDurationxf:not(op:yearMonthDuration-equal(A, B))xs:boolean
A ne Bxf:dayTimeDurationxf:dayTimeDurationxf:not(op:dayTimeDuration-equal(A, B)xs:boolean
A ne BGregorianGregorianxf:not(op:gYear-equal(A, B)) etc.xs:boolean
A ne Bxs:hexBinaryxs:hexBinaryxf:not(op:hex-binary-equal(A, B))xs:boolean
A ne Bxs:base64Binaryxs:base64Binaryxf:not(op:base64-binary-equal(A, B))xs:boolean
A ne Bxs:anyURIxs:anyURIxf:not(op:anyURI-equal(A, B))xs:boolean
A ne Bxs:QNamexs:QNamexf:not(op:QName-equal(A, B))xs:boolean
A ne Bxs:NOTATIONxs:NOTATIONxs:not(op:NOTATION-equal(A, B))xs:boolean
A gt Bnumericnumericop:numeric-greater-than(A, B)xs:boolean
A gt Bxs:booleanxs:booleanop:boolean-greater-than(A, B)xs:boolean
A gt Bxs:stringxs:stringop:numeric-greater-than(xf:compare(A, B), 0)xs:boolean
A gt Bxs:datexs:dateop:date-greater-than(A, B)xs:boolean
A gt Bxs:timexs:timeop:time-greater-than(A, B)xs:boolean
A gt Bxs:dateTimexs:dateTimeop:datetime-greater-than(A, B)xs:boolean
A gt Bxf:yearMonthDurationxf:yearMonthDurationop:yearMonthDuration-greater-than(A, B)xs:boolean
A gt Bxf:dayTimeDurationxf:dayTimeDurationop:dayTimeDuration-greater-than(A, B)xs:boolean
A lt Bnumericnumericop:numeric-less-than(A, B)xs:boolean
A lt Bxs:booleanxs:booleanop:boolean-less-than(A, B)xs:boolean
A lt Bxs:stringxs:stringop:numeric-less-than(xf:compare(A, B), 0)xs:boolean
A lt Bxs:datexs:dateop:date-less-than(A, B)xs:boolean
A lt Bxs:timexs:timeop:time-less-than(A, B)xs:boolean
A lt Bxs:dateTimexs:dateTimeop:datetime-less-than(A, B)xs:boolean
A lt Bxf:yearMonthDurationxf:yearMonthDurationop:yearMonthDuration-less-than(A, B)xs:boolean
A lt Bxf:dayTimeDurationxf:dayTimeDurationop:dayTimeDuration-less-than(A, B)xs:boolean
A ge Bnumericnumericop:numeric-less-than(B, A)xs:boolean
A ge Bxs:stringxs:stringop:numeric-greater-than(xf:compare(A, B), -1)xs:boolean
A ge Bxs:datexs:dateop:date-less-than(B, A)xs:boolean
A ge Bxs:timexs:timeop:time-less-than(B, A)xs:boolean
A ge Bxs:dateTimexs:dateTimeop:datetime-less-than(B, A)xs:boolean
A ge Bxf:yearMonthDurationxf:yearMonthDurationop:yearMonthDuration-less-than(B, A)xs:boolean
A ge Bxf:dayTimeDurationxf:dayTimeDurationop:dayTimeDuration-less-than(B, A)xs:boolean
A le Bnumericnumericop:numeric-greater-than(B, A)xs:boolean
A le Bxs:stringxs:stringop:numeric-less-than(xf:compare(A, B), 1)xs:boolean
A le Bxs:datexs:dateop:date-greater-than(B, A)xs:boolean
A le Bxs:timexs:timeop:time-greater-than(B, A)xs:boolean
A le Bxs:dateTimexs:dateTimeop:datetime-greater-than(B, A)xs:boolean
A le Bxf:yearMonthDurationxf:yearMonthDurationop:yearMonthDuration-greater-than(B, A)xs:boolean
A le Bxf:dayTimeDurationxf:dayTimeDurationop:dayTimeDuration-greater-than(B, A)xs:boolean
A is Bnodenodeop:node-equal(A, B)xs:boolean
A isnot Bnodenodexf:not(op:node-equal(A, B))xs:boolean
A << Bnodenodeop:node-before(A, B)xs:boolean
A >> Bnodenodeop:node-after(A, B)xs:boolean
A union Bnode*node*op:union(A, B)node*
A | Bnode*node*op:union(A, B)node*
A intersect Bnode*node*op:intersect(A, B)node*
A except Bnode*node*op:except(A, B)node*
A to Bxs:decimalxs:decimalop:to(A, B)xs:integer+
A , Bitem*item*op:concatenate(A, B)item*
Unary Operators
OperatorOperand typeFunctionResult type
+ Anumericop:numeric-unary-plus(A)numeric
- Anumericop:numeric-unary-minus(A)numeric

C References

C.1 Normative References

ISO/IEC 10646
ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E). Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 1993 (plus amendments AM 1 through AM 7).
ISO/IEC 10646-2000
ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 2000.
Unicode
The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.
Unicode3
The Unicode Consortium. The Unicode Standard, Version 3.0. Reading, Mass.: Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5.
XML
World Wide Web Consortium. Extensible Markup Language (XML) 1.0. W3C Recommendation. See http://www.w3.org/TR/2000/REC-xml-20001006
XML Names
World Wide Web Consortium. Namespaces in XML. W3C Recommendation. See http://www.w3.org/TR/REC-xml-names/
XML Schema
World Wide Web Consortium. XML Schema, Parts 0, 1, and 2. W3C Recommendation, 2 May 2001. See http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/ , http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ , and http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.
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, 30 April 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, 16 August 2002. See http://www.w3.org/TR/xquery-operators/
XQuery 1.0 Formal Semantics
World Wide Web Consortium. XQuery 1.0 Formal Semantics. W3C Working Draft, 16 August 2002. See http://www.w3.org/TR/query-semantics/.

C.2 Non-normative References

ISO 8601
International Organization for Standardization (ISO). Representations of Dates and Times, 2000-08-03. Available from http://www.iso.ch/
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, 16 August 2002. See http://www.w3.org/TR/xmlquery-use-cases.
XPath 2.0
World Wide Web Consortium. XML Path Language (XPath) Version 2.0. W3C Working Draft, 16 August 2002. See http://www.w3.org/TR/xpath20/
XQueryX 1.0
World Wide Web Consortium. XQueryX, Version 1.0. W3C Working Draft, 7 June 2001. See http://www.w3.org/TR/xqueryx [Ed. Note: As of the date of this publication, XQueryX has not incorporated recent language changes; it will be made consistent with this document in its next edition.]
XSLT 2.0
World Wide Web Consortium. XSL Transformations (XSLT) 2.0. W3C Working Draft. See http://www.w3.org/TR/xslt20/

C.3 Background References

Lorel
Serge Abiteboul, Dallan Quass, Jason McHugh, Jennifer Widom, and Janet L. Wiener. The Lorel Query Language for Semistructured Data. International Journal on Digital Libraries, 1(1):68-88, April 1997. See "http://www-db.stanford.edu/~widom/pubs.html
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. In Lecture Notes in Computer Science, Springer-Verlag, Dec. 2000. Also available at http://www.almaden.ibm.com/cs/people/chamberlin/quilt_lncs.pdf. See also http://www.almaden.ibm.com/cs/people/chamberlin/quilt.html.
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.)
XML-QL
Alin Deutsch, Mary Fernandez, Daniela Florescu, Alon Levy, and Dan Suciu. A Query Language for XML. See http://www.research.att.com/~mff/files/final.html
XPath 1.0
World Wide Web Consortium. XML Path Language (XPath) Version 1.0. W3C Recommendation, Nov. 16, 1999. See http://www.w3.org/TR/xpath.html
XQL
J. Robie, J. Lapp, D. Schach. XML Query Language (XQL). See http://www.w3.org/TandS/QL/QL98/pp/xql.html.
YATL
S. Cluet, S. Jacqmin, and J. Simeon. The New YATL: Design and Specifications. Technical Report, INRIA, 1999.

C.4 Informative Material

Character Model
World Wide Web Consortium. Character Model for the World Wide Web. W3C Working Draft. See http://www.w3.org/TR/charmod/
RFC2396
T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax. IETF RFC 2396. See http://www.ietf.org/rfc/rfc2396.txt.
Unicode
Unicode Consortium. The Unicode Standard. See http://www.unicode.org/unicode/standard/standard.html.
XML Infoset
World Wide Web Consortium. XML Information Set. W3C Recommendation 24 October 2001. See http://www.w3.org/TR/xml-infoset/
XPointer
World Wide Web Consortium. XML Pointer Language (XPointer). W3C Last Call Working Draft 8 January 2001. See http://www.w3.org/TR/WD-xptr
XSLT 1.0
World Wide Web Consortium. XSL Transformations (XSLT) 1.0. W3C Recommendation. See http://www.w3.org/TR/xslt

D Glossary

Ed. Note: To be done.

E XPath 2.0 and XQuery 1.0 Issues (Non-Normative)

Values for Status has the following meaning:

resolved: a decision has been finalized and the document updated to reflect the decision.

decided: recommendations and decision(s) has been made by one or more of the following: a task-force, XPath WG, or XQuery WG.

draft: a proposal has been developed for possible future inclusion in a published document.

active: issue is actively being discussed.

unassigned: discussion of issue deferred.

subsumed: issue has been subsumed by another issue.

(parameters used: kwSort: cluster, kwFull: brief, kwDate: 00000000).


NumClClusterStatusLocusDescriptionOriginator
293activexquery Cdata and CharRef SemanticsMichael Rys
323activexpath Should "unordered" be included in XPath?XSL/XQuery joint
134(de)reference-exprdecidedxquery Dereference Operator and LinksJonathan Robie
92(in)equality-operatorsactivexpath Deep equalityJonathan
96(in)equality-operatorsactivexpath Normalized EqualityMary Fernandez
283-value-logicactivexpath Do we need and3(), or3(), not3() built in?XSL WG
2153-value-logicactivexpath Should we have a 3-valued form of quantifiers?Andrew Eisenberg
132attribute accessorsdecidedxfo Attribute Name, Attribute ContentDon Chamberlin
113axesdecidedxpath What should the mechanism be for axis subsetting?jmarsh@microsoft.com
328cdata sectionactivexquery What does CDATA section constructor construct?Michael Kay
177TFchoice-contextactivexpath Consistency of functions that take boolean formal argumentXPath-TF
256Dcollectionsactivexpath What is return type of colections?XPath TF
257Dcollectionsactivexpath Does collection() always return same result?XPath TF
333conformanceactivexpath Optional Features vs. Conformance LevelsXPath TF
169conformanceunassignedxquery Missing conformance sectionJonathan
238consistencyactivexpath Consistency: tradeoff between interoperability and efficiencyPhil Wadler
239consistencyactivexpath Consistency: bracketing of nested expressionsPhil Wadler
240consistencyactivexpath Consistency: parenthesizing test expressionsPhil Wadler
241consistencyactivexpath Consistency: keywordsPhil Wadler
252consistencyactivexquery "sort by" rather than "sortby" for consistency?Phil Wadler
286constructor-expractivexquery Element Construction vs StreamingMichael Rys
288constructor-expractivexquery Element Constructor Attribute OrderMichael Rys
289Tconstructor-expractivexquery Attribute Value Construction from ElementsMichael Rys
290constructor-expractivexquery Element Attribute Constructor Name TypeMichael Rys
291Tconstructor-expractivexquery Element Construction anySimpleType Sequence ContentMichael Rys
292constructor-expractivexquery Element Construction Sequence vs Multi-exprMichael Rys
146constructor-exprdecidedxquery Jonathan
145constructor-exprunassignedxquery Copy and Reference SemanticsXQuery Editors
329constructorsactivexquery Duplicate attribute constructorsMichael Kay
143constructor-syntaxunassignedalgebra XML Constructor Jonathan Robie
230Dcontextdecidedxpath Context document adequate for multiple docuemnts?Michael Rys
258Ddocumentsactivexpath Identity of Document NodesJonathan Robie
170Ddocumentsunassignedxquery Document collectionsXQuery WG
97erroractivexpath How should the error object be supported?Editor
98erroractivexpath General discussion of errorsXML Query WG
99errorunassignedxquery TRY/CATCH and error()XQuery Editors
160execution-modelactivexquery Naive Implementation StrategyMarton Nagy
226existential expressionsactivexpath Existential ExpressionsMike Kay
317extensionsactivexquery XQuery Extension MechanismsAndrew Eisenberg
272external-functionsactivexpath External FunctionsMichael Kay
273external-objectsactivexpath External ObjectsMichael Kay
231fallbackdecidedxpath data(SimpleValue) is error or no-op?XSL WG
163filterunassignedalgebra Typing of FilterJerome Simeon
217focusdecidedxpath Context document in focusMichael Rys
265FTTF-xml:langactivexpath-fulltext How do we determine the xml:lang for a node if it inherits xml:lang from a higher-level node?FTTF
266FTTF-xml:langactivexpath-fulltext Do we support the sublanguage portion of xml:lang?FTTF
105function-appactivexpath Implicit current node for functions?XQuery Editors
102function-appdecidedxpath Functions on Empty SequencesXQuery
103function-appdecidedxpath Functions on SequencesXQuery
107function-appdecidedxpath Path iterationXQuery
180functionsactivexpath Functions expecting complex-valued argumentsXPath-TF
327functionsactivexpath XSL/XQuery joint
124functionsunassignedxquery External FunctionsXQuery Editors
157functionsunassignedxquery Function LibrariesXQuery Editors
223functions externalactivexquery We need a way to declare external functionsMichael Rys
3grammaractivexpath What should be the precedence of a RangeExpr be?Editor
254grammaractivexpath Should the lexical details be in document?XPath TF
168groupbyunassignedxquery GROUPBYXML Query
59TINSTANCEOF-exprdecidedxpath We need precise semantics for instanceof.mhkay@iclway.co.uk
295lexical-representationactivexquery Lexical Representation of Atomic Valuesxquery/xsl f2f
151literal-XMLunassignedxquery Cutting and pasting XML into XQueryXQuery Editors
166miscellaneousunassignedxquery Excluding Undesired ElementsDon Chamberlin
74module-semanticsactivexquery Module syntaxXQuery Editors
75module-semanticsunassignedxquery Importing ModulesXQuery Editors
79module-syntaxunassignedxquery EncodingJonathan Robie
228namespace functionsactivexpath Should we keep the default function namespace, and the xf: namespace?Scott Boag
219namespacesactivexquery Context: namespacesMichael Rys
222namespacesactivexquery Allow redefinition of namespace prefixes?Michael Rys
247namespacesactivexpath What does default namespace(s) affect?XPath TF
319namespacesactivexquery Namespace definitions and in-scope namespacesXPath TF
85node-equalitydecidedxfo Identity-based equality operatorAlgebra Editors
86node-equalitydecidedxpath Set operations based on valueXQuery Editors
186node orderdecidedxpath Ordering of result of union, intersect, and except operatorsXPath Editors
184Tnode-typesdecidedxpath Need ability to test for Comments, PIsF&O TF
187operatorsactivexfo Operations supported on date/time typesXPath Editors
189operatorsactivexpath Supported combinations of types for comparison operatorsXPath Editors
210order sequencesactivexpath Order of sequencesPhil Wadler
234order sequencesactivexpath Who defines sorting order of ()?Phil Wadler
296path-semanticsdecidedxpath What is definition of leading "/"?XQuery Editors
5reserved-wordsactivexpath Reserved wordsXQuery
123serializationactivexquery Linearization/SerializationXQuery
244serializationactivexquery CDATA sections and serializationMichael Rys
195sortactivexquery Semantics of sorting heterogeneous sequencesXPath Editors
220sortactivexpath Should there be a way to explicitly sort in document order?Michael Rys
242sortactivexquery Sortby on partially ordered values?Michael Rys
243sortactivexpath Provide an example of sorting "disappearing"Michael Rys
251sortactivexquery Sorting "input to loop", not the resultPhil Wadler
300sortactivexquery Should sorting of untyped data be prohibited?XPath TF
318sortactivexpath Add 'order by' clause to FLWR?Jonathan Robie
155sortunassignedxquery Sorting by Non-exposed DataMichael Rys
109syntaxactivexpath Need text to disambiguate Lexical Structure?mhkay@iclway.co.uk
233syntaxactivexpath Simpler FLWR syntax?Phil Wadler
235syntaxactivexpath Need parenthesis in conditional expression?Phil Wadler
236syntaxactivexpath SimpleType preceded by a keyword?Phil Wadler
237syntaxactivexpath Need parenthesis in type switch expression?Phil Wadler
246syntaxactivexquery Nested XQuery comments allowed?Michael Rys
267syntaxactivexpath Syntax problems with "validate"XPath TF
287syntaxactivexpath Functional Status of CommaMichael Rys
315syntaxactivexpath Whitespace allowed in the name of a variable!Dana
112syntaxdecidedxpath Leading MinusXML Query
144syntaxdecidedxquery Escaping Quotes and ApostrophesXML Query
212syntaxdecidedxpath Is "datatype" a suitable production name?Phil Wadler
229syntaxdecidedxpath Do we need both << and precedes?XQuery/XSL WGs
208syntax curly braceactivexquery Multiple curly braces allowed?Phil Wadler
245syntax curly braceactivexquery Are {} in text evaluated?Michael Rys
227syntax dereferenceactivexpath Syntax for dereference?Don Chambrelin
232syntax operators dateactivexpath Use "+" and "-" on dates and durations?Phil Wadler
283syntax-productionsactivexpath Is the DocumentElement syntax production necessary?Jonathan Robie
213syntax quotesactivexpath How to get quotes etc in string literals?Andrew Eisenberg
261syntax quotesactivexquery Quoting rules in nested expressions in attribute value constructionMichael Rys
214syntax strings in attributesactivexquery Strings in attributesAndrew Eisenberg
183Ttext-nodesactivexpath Text nodes - lexical structure and typed formXPath TF
192Ttype constructed elementdecidedxquery Type of a newly constructed elementXPath Editors
172Ttyped-value/data()activexpath Some functions taking node sequences and implicitly map?XPath TF
54type-errorsactivexquery Queries with Invalid ContentXQuery Editors
185type exceptiondecidedxpath Always explicit cast?Phil Wadler
200Ttypesactivexpath Semantics of "only"XPath Editors
206Ttypesactivexpath Typing support in XPathMike Kay
224Ttypesactivexquery Why do we want to allow optional returns and DataType?Michael Rys
297Ttypesactivexpath Should XPath have "type binding" in variable?XQuery Editors
298Ttypesactivexpath Add Schema type names for sequences of homogeneous types?XPath TF
301Ttypesactivexpath Supporting SQL/XML mappings in Basic XQueryJonathan Robie
302Ttypesactivexpath Support for arbitrary XML documentsJonathan Robie
303Ttypesactivexpath Define "scale-down" mappings?Jonathan Robie
304Ttypesactivexpath Declare required conformance features?Don Chamberlin
305Ttypesactivexpath Schema Import Feature prerequisite for Static Typing Feature?Don Chamberlin
306Ttypesactivexpath PSVI to Data Model mapping part of normative text?Don Chamberlin
307Ttypesactivexpath Schema Types from input documents?Don Chamberlin
308Ttypesactivexpath Type SoundnessDon Chamberlin
309Ttypesactivexpath What should be the type of an error value?Don Chamberlin
310Ttypesactivexquery Are the children of a newly constructed element typed?Dana F
312Ttypesactivexquery What to do about list types?XQuery WG
313Ttypesactivexquery What to do about union types?XQuery WG
314Ttypesactivexquery Partial support for SCHEMA IMPORT in Basic XQuery?XQuery WG
316Ttypesactivexpath Is AnySimpleType = AnySimpleType*?Michael Rys
320Ttypesactivexquery Should different conformance levels give the same result for the same query and data?Anders Berglund
325Ttypesactivexpath Refering to element that is not in the in-scope schema def.XQuery
326Ttypesactivexpath Semantics of element foo of type TXQuery
330Ttypesactivexquery Should "some" do type filtering?Michael Kay
331Ttypesactivexpath Static vs. dynamic dispatch for arithmeticsDana Florescu
332typesactivexpath Schema Import, Static Typing: what is interoperable?XPath TF
196Ttypesdecidedxpath Concrete syntax for datatype declarationsXPath Editors
197Ttypesdecidedxpath Need "attribute of type"?XPath Editors
198Ttypesdecidedxpath Syntax for named typingXPath Editors
199Ttypesdecidedxpath Support for locally declared types?XPath Editors
211Ttypesdecidedxpath Treat and structural vs named typingPhil Wadler
40Ttype-semanticsactivexquery Correspondence of TypesJerome Simeon
42Ttype-semanticsactivexquery Implementation of and conformance levels for static type checking Don
43Ttype-semanticsactivexquery Defining Behavior for Well Formed, DTD, and Schema DocumentsDon Chamberlin
44Ttype-semanticsactivexquery Support for schema-less and incompletely validated documents Don Chamberlin/Mary Fernandez
46Ttype-semanticsactivexquery typeof() functionJonathan
48Ttype-semanticsactivealgebra CASE not a subtypeXML Query
255Ttype-semanticsactivexpath What are the operators on a derived type?Don Chamberlin
260Ttype-semanticsactivexpath Implicit data() on instanceof?Michael Rys
262Ttype-semanticsactivexpath Definition of data() on elements with known complex typeXPath TF
268Ttype-semanticsactivexpath xsd:string and anySimpleType'd data behave the same?XQuery WG
269Ttype-semanticsactivexpath Can we get rid of the unknown keywordXQuery WG
270Ttype-semanticsactivexpath Typing, coercions, and conformanceXQuery WG
271Ttype-semanticsactivexpath Type compatibility of heterogeneous union typesXQuery WG
274Ttype-semanticsactivexpath Text-node-only implementation possible?XSL WG
275Ttype-semanticsactivexpath Should validation also check identity constraints?Jonathan Robie
276Ttype-semanticsactivexpath Does validation introduce new xsi:type attributes?Jonathan Robie
277Ttype-semanticsactivexpath Should validate introduce xsi:type?Jonathan Robie
278Ttype-semanticsactivexpath Does //@xsi:type match an xsi:type attribute?Jonathan Robie
279Ttype-semanticsactivexpath Should there be a lightweight cast?Jonathan Robie
280Ttype-semanticsactivexpath Do we need to distinguish atomic simple types and list simple types?Jonathan Robie
281Ttype-semanticsactivexpath Representing the type name of untyped character dataJonathan Robie
282Ttype-semanticsactivexpath xs:numeric typeJonathan Robie
284Ttype-semanticsactivexpath Static Named TypingJonathan Robie
285Ttype-semanticsactivexpath Is the QName denoting type information optional or required?Phil Wadler
294Ttype-semanticsactivexquery Should all elements and attributes have type annotations?Philip Wadler
41Ttype-semanticsdecidedxquery Static type-checking vs. Schema validationMary Fernandez
45Ttype-semanticsdecidedxquery Names in Type DefinitionsDon
47Ttype-semanticsdecidedxquery Subtype SubstitutabilityXQuery Editors
51TFtype-semanticsdecidedxquery Function ResolutionXQuery Editors
253TFtype-semanticsdecidedxpath CAST as simple type of a node typeMichael Rys
263Ttype-semanticsdecidedxpath Definition of data() on elements with unknown type, whose content may be simple or complexXPath TF
56Ttype-syntaxactivexquery Human-Readable Syntax for TypesAlgebra Editors
57Ttype-syntaxactivexquery Inline XML Schema DeclarationsDon Chamberlin
164updatesunassignedxquery UpdatesXQuery Editors
321validateactivexquery Is validate strict or lax?XSL/XQuery joint
322validateactivexquery "validate" strict/lax override?XSL/XQuery joint
225variablesactivexpath Variable redefinition allowed?Mike Kay
250variablesactivexquery Declaring Variables in PrologJonathan Robie
264variablesactivexpath Shadowing of VariablesMichael Kay
324variablesactivexquery How can variables be bound external to XQuery itself?XSL/XQuery joint
207variablesdecidedxpath Variable names: QNames or NCnames?Ashok Malhotra
191whitespaceactivexquery Whitespace handling in element constructorsXPath Editors
299whitespaceactivexquery Does character reference to whitespace change whitespace handling?XPath TF
311whitespaceactivexquery Whitespace and Attribute Constructors
218wildcardsactivexpath What wildcards; namespaceprefix?Michael Rys
193Txml non representableactivexquery Construction of non representable XMLXPath Editors
130xquery-alignmentactivealgebra Algebra MappingXQuery Editors
152xqueryxactivexqueryx XML-based SyntaxXML Query WG
153xqueryxactivexquery Escape between syntaxesJerome Simeon

3. xpath-issue-rangeexpr-precidence: What should be the precedence of a RangeExpr be?

Locus: xpath Cluster: grammar Status: active
Originator: Editor

Description

What should be the precedence of a RangeExpr? The XQuery grammar has it in a bit different place than is listed here.

5. xpath-issue-reserved-words: Reserved words

Locus: xpath Cluster: reserved-words Status: active
Originator: XQuery

Description

XPath 1.0 has no reserved words. The current XQuery spec attempts to avoid reserved words but the result is that the XQuery grammar relies heavily on lexing tricks that make it difficult to document and difficult to extend. There is currently a substantial feeling in the XQuery group that the language should have some reserved words, which would be an incompatible change from XPath 1.0.

XSL WG Position: Exceptionally strong feeling that requiring element names that match a reserved word to be escaped is utterly unacceptable. If reserved words are required they must start with an escape character so they cannot conflict with element names. Attempt to maintain grammar and revisit this issue as necessary. We recognize that there is a problem but solutions are all distasteful.

Interactions and Input

Cf. 5. Reserved Words:

Subsumes: [link to subsumed issue: #xquery-xpath-issue-reserved-words] .

Cf. Keywords in XQuery

Subsumes: [link to subsumed issue: #xquery-reserved-keywords] .

28. xpath-issue-not-logic: Do we need and3(), or3(), not3() built in?

Locus: xpath Cluster: 3-value-logic Status: active
Originator: XSL WG

Description

Should the 3-valued logic functions be part of the XPath function library? Note that they can be implemented as user functions (not as efficient as a "native" implementation). We may want to include the user definition as an example.

40. xquery-type-correspondence: Correspondence of Types

Issue Class: T Locus: xquery Cluster: type-semantics Status: active
Originator: Jerome Simeon

Description

Section 2.9, on functions, portrays XQuery as a statically typed language, but the mechanisms by which static typing is established are still being developed by the XML Query Algebra editorial team. A complete accounting for type requires that the XML Query Algebra conform completely to the XML Schema type system, and that many open issues be resolved.

The semantics of XQuery are defined in terms of the operators of the XML Query Algebra. The mapping of XQuery operators into Algebra operators is still being designed, and may result in some changes to XQuery and/or the Algebra. The type system of XQuery is the type system of XML Schema. Work is in progress to ensure that the type systems of XQuery, the XML Query Algebra, and XML Schema are completely aligned. The details of the operators supported on simple XML Schema datatypes will be defined by a joint XSLT/Schema/Query task force.

41. xquery-static-versus-validate: Static type-checking vs. Schema validation

Issue Class: T Locus: xquery Cluster: type-semantics Status: decided
Originator: 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).

This item is a duplicate of the Formal Semantics issue [link to member only information] .

Actual Resolution

Decision by: xpath-tf on 2002-05-07 ([link to member only information] )

Decision by: xquery on 2002-05-22 ([link to member only information] )

Decision by: xsl on 2002-06-27 ([link to member only information] )

Addressed by the "Named Typing" proposal.

Accepting text in 2002-04-30 public draft.

42. xquery-type-conformance: Implementation of and conformance levels for static type checking

Issue Class: T Locus: xquery Cluster: type-semantics Status: active
Originator: Don

Description

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 XQuery, in which some processors (or some processing modes) are more permissive about types. This would allow XQuery implementations that do not understand all of Schema, and it would allow customers some control over the cost/benefit tradeoff of type checking.

This item is a duplicate of the Formal Semantics issue [link to member only information] .

Proposed Resolution

Jonathan and Don to present a potential consensus proposal at the f2f (This should be a very short proposal). Note: Perhaps we should seriously consider writing the conformance section for the next set of publications.

43. xquery-define-schema-variants: Defining Behavior for Well Formed, DTD, and Schema Documents

Issue Class: T Locus: xquery Cluster: type-semantics Status: active
Originator: Don Chamberlin

Description

We should specify the behavior of XQuery for well formed XML, XML validated by a schema, and XML validated by a DTD.

Proposed Resolution

The mapping of a DTD validated or well formed document still needs to be defined in the Data Model.

44. xquery-schemaless: Support for schema-less and incompletely validated documents

Issue Class: T Locus: xquery Cluster: type-semantics Status: active
Originator: Don Chamberlin/Mary Fernandez

Description

This is related to [link to resolved issue: #xquery-schema-import] . 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.

This item is a duplicate of the Formal Semantics issue [link to member only information] .

Proposed Resolution

Some aspects addressed by the "Named Typing" proposal.

The Data Model work still needs to be done.

Open questions: What is the result of a failed validation? Can you inspect the result?

45. xquery-names-type-definition: Names in Type Definitions

Issue Class: T Locus: xquery Cluster: type-semantics Status: decided
Originator: Don

Description

Does the definition of a type include both element-names and element-contents (as in the Formal Semantics document), or only element-contents (as in XML Schema)?

Actual Resolution

Addressed by the "Named Typing" proposal.

Decision by: xpath-tf on 2002-05-07 ([link to member only information] )

Decision by: xquery on 2002-05-22 ([link to member only information] )

Decision by: xsl on 2002-06-27 ([link to member only information] )

Accepting text in 2002-04-30 public draft.

46. xquery-typeof: typeof() function

Issue Class: T Locus: xquery Cluster: type-semantics Status: active
Originator: Jonathan

Description

Do we need a function that returns the type name of its operand? If so, what should it return if the operand is an element with a given xsi:type - the element name? the name of the type denoted by xsi:type? Specification of this function requires more work on types in XQuery.

47. xquery-subtype-substitutability: Subtype Substitutability

Issue Class: T Locus: xquery Cluster: type-semantics Status: decided
Originator: XQuery Editors

Description

Should XQuery 1.0 support subtype substitutability for function parameters?

If subtype substitutability is not supported in XQuery Version 1, the motivation for TYPESWITCH is weakened and the decision to support TYPESWITCH should be revisited.

Actual Resolution

Addressed by the "Named Typing" proposal.

Decision by: xpath-tf on 2002-05-07 ([link to member only information] )

Decision by: xquery on 2002-05-22 ([link to member only information] )

Decision by: xsl on 2002-06-27 ([link to member only information] )

Accepting text in 2002-04-30 public draft.

48. xquery-typeswitch-case-not-subtype: CASE not a subtype

Issue Class: T Locus: algebra Cluster: type-semantics Status: active
Originator: XML Query

Description

If the types in the CASE branches are not subtypes of the TYPESWITCH, is this an error, or are these branches simply never executed? If the latter, should we require a warning?

51. xquery-function-resolution: Function Resolution

Issue Class: TF Locus: xquery Cluster: type-semantics Status: decided
Originator: XQuery Editors

Description

More detailed rules need to be developed for function resolution. What kinds of function overloading are allowed? A promotion hierarchy of basic types needs to be specified. The issue of polymorphic functions with dynamic dispatch needs to be studied. Can overloaded functions be defined such that the parameter-type of one function is a subtype of the parameter-type of another function? If so, what are the constraints on the return-types of these functions? Is function selection based on the static type of the argument or on the dynamic type of the argument (dynamic dispatch, performed at execution time)? If XQuery supports dynamic dispatch, is it based on all the arguments of a function or on only one distinguished argument?

Observation: This is a very complex area of language design. If it proves too difficult to solve in the available time, it may be wise to take a simple approach such as avoiding dynamic dispatch in Version 1 of XML Query.

Proposed Resolution

The XML Query Formal Semantics does not support overloading or dynamic dispatch. We will attempt to simplify XML Query Level 1 by omitting these, unless it becomes clear that they are needed. We realize that this might happen.

Actual Resolution

Decision by: xpath-tf on 2002-04-30 ([link to member only information] )

Decision by: xquery on 2002-05-22 ([link to member only information] )

Decision by: xsl on 2002-06-27 ([link to member only information] )

Mike: We dealt with by saying that there is only one function and the use typeswitch semantics.

54. xquery-invalid-content: Queries with Invalid Content

Locus: xquery Cluster: type-errors Status: active
Originator: XQuery Editors

Description

Is it an error for a query to specify content that may not appear, according to the schema definition? Consider the following query:

invoice//nose

If the schema does not allow a nose to appear on an invoice, is this query an error, or will it simply return an empty list?

Proposed Resolution

Addressed by the "Named Typing" proposal, but needs more work.

56. xquery-type-syntax: Human-Readable Syntax for Types

Issue Class: T Locus: xquery Cluster: type-syntax Status: active
Originator: Algebra Editors

Description

The Algebra has a syntax for declaring types. Up to now, XQuery uses XML Schema for declaring types. Is this sufficient? Some important questions:

  1. Are type names sufficient, or does XQuery really need its own syntax for declaring types?
  2. Would Normalized Universal Names (derived from MSL) be sufficient for type names?
  3. How will type names be bound to definitions?

57. xquery-inline-xml-schema: Inline XML Schema Declarations

Issue Class: T Locus: xquery Cluster: type-syntax Status: active
Originator: Don Chamberlin

Description

Do we need to allow inline XML schema declarations in the prolog of a query? The following example shows one potential syntax for this. It extends the namespace declaration to allow literal XML Schema text to occur instead of a URI in a namespace declaration. The implementation would then assign an internal URI to the namespace.

		  NAMESPACE fid =
		  "http://example.org/fiddlefaddle.xsd"

  NAMESPACE loc =  [[
      <xsd:schema xmlns:xsd = "http://www.w3.org/2000/10/XMLSchema">
      <xsd:simpleType name="myInteger">
      <xsd:restriction base="xsd:integer">
      <xsd:minInclusive value="10000"/>
      <xsd:maxInclusive value="99999"/>
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:schema>
  ]]


  FUNCTION string-to-myInteger ($s STRING) RETURNS loc:myInteger
  {
   If the facets of loc:myInteger are not satisfied,
   this function raises an error.

    LET $t := round(number($s))
    RETURN TREAT AS loc:myInteger($t)
  }


  string-to-myInteger("1023")

59. xpath-issue-instanceof-symantics: We need precise semantics for instanceof.

Issue Class: T Locus: xpath Cluster: INSTANCEOF-expr Status: decided
Assigned to: xquery Originator: mhkay@iclway.co.uk

Description

The semantics of the instanceof operator are not defined over all operands, e.g. sets of several nodes, sequences of several values, etc. What should the symantics be for these types? Should these semantics be defined in the F&O document?

Actual Resolution

Decision by: xsl on 2002-06-27 ([link to member only information] )

Decision by: xquery on 2002-07-17 ([link to member only information] )

The issue is "dead", in the sense that the April draft contains text that everyone is happy with.

74. xquery-module-syntax: Module syntax

Locus: xquery Cluster: module-semantics Status: active
Originator: XQuery Editors

Description

The definition and syntax of a query module are still under discussion in the working group. The specifications in this section are pending approval by the working group.

Future versions of the language may support other forms of query modules, such as update statements and view definitions.

75. xquery-import: Importing Modules

Locus: xquery Cluster: module-semantics Status: unassigned
Originator: XQuery Editors

Description

The means by which a query module gains access to the functions defined an an external function library remains to be defined.

Should xmlns only be respected for construction, Xquery expressions but not functions, or also functions?

79. xquery-encoding: Encoding

Locus: xquery Cluster: module-syntax Status: unassigned
Originator: Jonathan Robie

Description

Does XQuery need a way to specify the encoding of a query? For instance, should the prolog allow statements like the following?

ENCODING utf-16

85. xquery-equality-identity: Identity-based equality operator

Locus: xfo Cluster: node-equality Status: decided
Originator: Algebra Editors

Description

Do we need an identity-based equality operator? Please justify your answer with sample queries. Note that XPath gets along without it.

Interactions and Input

Cf. Should we use is and isnot instead of == and !==.

Proposed Resolution

The '==' operator is already defined in the F&O document and used in XQuery use cases.

Actual Resolution

Decision by: xpath-tf on 2002-04-30 ([link to member only information] )

Decision by: xquery on 2002-05-22 ([link to member only information] )

Decision by: xsl on 2002-06-27 ([link to member only information] )

The '==' is in the document and usecases.

Note that it has been decided to change "==" to "is".

86. xquery-set-operators-on-values: Set operations based on value

Locus: xpath Cluster: node-equality Status: decided
Originator: XQuery Editors

Description

The definitions of UNION, INTERSECT, and EXCEPT for simple values are still under discussion. It is not clear that these operators should apply to simple values, because simple values do not have a concept of node identity. If these operators are defined for simple values, perhaps they should have a lower precedence than arithmetic operators.

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.4.

Proposed Resolution

Decision by: xsl on 2002-01-22 ([link to member only information] )

The XSL WG felt that these operators should operate on nodes only and not be overloaded to work on "values" as well. Functions should be used for the "analogous" functionality on values. Action to Ashok to write a proposal. It was noted that one might well want to to a "value" union operating on nodes (where the typed value of each is extracted).

Actual Resolution

Decision by: xsl on 2002-01-22 ([link to member only information] )

Decision by: xquery on 2002-02-28 ([link to member only information] )Xquery acceptance of XSL proposal

These operators operate on nodes only and are not overloaded to work on "values" as well. Functions are to be used for the "analogous" functionality on values.

92. xquery-deep-equality: Deep equality

Locus: xpath Cluster: (in)equality-operators Status: active
Originator: Jonathan

Description

In XPath, <book><title> Mark Twain </title></book> and <book><author> Mark Twain </author></book> are treated as equal in comparisons. Is this acceptable for us? Do we need another notion of deep equality? If so, what are the compatibility issues with XPath?

96. xquery-normalized-equality: Normalized Equality

Locus: xpath Cluster: (in)equality-operators Status: active
Originator: Mary Fernandez

Description

When elements are compared, are comments and PIs considered in the comparison? How is whitespace handled? Do we need to allow more than one way to handle these in comparisons?

97. xpath-issue-error-object: How should the error object be supported?

Locus: xpath Cluster: error Status: active
Originator: Editor

Description

How should the error object be supported? How does the error object relate to exceptions?

98. xquery-general-errors: General discussion of errors

Locus: xpath Cluster: error Status: active
Originator: XML Query WG

Description

This document does not have a general discussion of errors, when they are raised, and how they are processed. This is needed.

99. xquery-try-catch-error: TRY/CATCH and error()

Locus: xquery Cluster: error Status: unassigned
Assigned to: Dana Originator: XQuery Editors

Description

We believe the following approach to error handling would be very useful - (1) introduce TRY <expression> CATCH <expression>, similar to try/catch in OO languages. Instead of having "throw" to throw objects, use error(<expression>), bind the result of the expression to the variable $err, and allow $err to be used in the CATCH clause.

Proposed Resolution

Dana Florescu has been assigned the task of writing a proposal for this.

102. null-issue-functions-on-empty: Functions on Empty Sequences

Locus: xpath Cluster: function-app Status: decided
Originator: XQuery

Description

XQuery-Null-Issue-7: Question: What should happen if a function expecting one element is invoked on an empty sequence?

Actual Resolution

It's an error.

Text is in Working Draft 2001-11-28 sec 2.1.2, paragraph 6, item 1.3.

Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.

Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification.

103. null-functions-on-sequences-a: Functions on Sequences

Locus: xpath Cluster: function-app Status: decided
Originator: XQuery

Description

What should happen if a function expecting one element is invoked on a sequence of more than one element?

Actual Resolution

It's an error.

Text is in Working Draft 2001-11-28 sec 2.1.2, paragraph 6, item 1.1.

Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.

Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification.

105. xquery-implicit-current-node: Implicit current node for functions?

Locus: xpath Cluster: function-app Status: active
Originator: XQuery Editors

Description

Many XPath functions and node-tests implicitly operate on the current node if no argument is specified. Should this apply to all functions? All unary functions? Only certain functions?

107. null-functions-on-sequences-b: Path iteration

Locus: xpath Cluster: function-app Status: decided
Originator: XQuery

Description

How should the current node be passed to a function in a path-step?

Actual Resolution

Using dot notation (".").

Text is in Working Draft 2001-11-28 sec 2.1.1.2, paragraph 4.

Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.

Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification.

109. xpath-issue-lexical-disambiguating-text: Need text to disambiguate Lexical Structure?

Locus: xpath Cluster: syntax Status: active
Originator: mhkay@iclway.co.uk

Description

There seems to be a lot of material missing here, for example the rules for disambiguating operator names from NCNames, the two uses of "*", etc. The statement "the longest possible token" means the longest sequence that would form a token in the token-space of the grammar, not the longest that would be valid in the current syntactic context.

112. xquery-leading-minus: Leading Minus

Locus: xpath Cluster: syntax Status: decided
Originator: XML Query

Description

Should leading minus/plus be treated as unary operators or as part of a numeric literal? Or should both be supported?

Actual Resolution

Decision by: xsl on 2002-06-27 ([link to member only information] )

Decision by: xquery on 2002-07-17 ([link to member only information] )

The issue is "dead", in the sense that the April draft contains text that everyone is happy with.

113. xpath-issue-axis-subsetting: What should the mechanism be for axis subsetting?

Locus: xpath Cluster: axes Status: decided
Originator: jmarsh@microsoft.com

Description

Why is axis availability part of the run-time context? Myaxis::foo should be a syntax error. This seems like a really clunky mechanism for subsetting. The alternative, as Mike Kay presented, is to provide a set of booleans telling if the given axis is available.

Proposed Resolution

Proposed resolution: Axis subsetting should be done at the grammar level, similar to how XSLT pattern matching is specified.

Actual Resolution

Decision by: xpath-tf on 2002-04-30 ([link to member only information] )

Decision by: xquery on 2002-05-22 ([link to member only information] )

Decision by: xsl on 2002-06-27 ([link to member only information] )

Done at grammar level.

123. null-serialization: Linearization/Serialization

Locus: xquery Cluster: serialization Status: active
Originator: XQuery

Description

When an empty element is linearized, should it get xsi:nil="True"? Option 8A: Yes. Option 8B: No. Option 8C: Only if it is declared to have required content and to be "nilable".

124. xquery-external-functions: External Functions

Locus: xquery Cluster: functions Status: unassigned
Originator: XQuery Editors

Description

An extensibility mechanism needs to be defined that permits XQuery to access a library of functions written in some other programming language such as Java.

Some sources of information: the definition of external functions in SQL, the implementation of external functions in Kweelt.

130. algebra-mapping: Algebra Mapping

Locus: algebra Cluster: xquery-alignment Status: active
Assigned to: Jerome Originator: XQuery Editors

Description

The algebra mapping is incomplete and out of date.

Proposed Resolution

Jerome has created a new version of the mapping, with help from Mary, Dana and Mugur.

132. xquery-attribute-name-content: Attribute Name, Attribute Content

Locus: xfo Cluster: attribute accessors Status: decided
Originator: Don Chamberlin

Description

We need functions to return the name of an attribute and the content of an attribute.

Proposed Resolution

My proposal is to create a separate section in the F&O document listing the accessors in the data model that are supported. The semantics would still be specified in the data model document. Similarly, we would add a section that listed the functions in the evaluation context that are supported. The semantics for these functions would be in the XPath document as decided this morning.

Actual Resolution

Decision by: xpath-tf on 2002-04-30 ([link to member only information] )

Decision by: xquery on 2002-05-22 ([link to member only information] )

Decision by: xsl on 2002-06-27 ([link to member only information] )

Section "Accessors" has been added to F&O.

134. xquery-dereference-links: Dereference Operator and Links

Locus: xquery Cluster: (de)reference-expr Status: decided
Originator: Jonathan Robie

Description

Does the dereference operator work on links, such as XLink or HTML href? Should we also support KEY/KEYREF? In general, our handling of references needs a lot of work.

In general, how are the semantics of the dereference operator defined?

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.3.

Actual Resolution

Decision by: xsl on 2002-01-22 ([link to member only information] )

Decision by: xquery on 2002-02-28 ([link to member only information] )

Acceptance of text in December 2001 published Working Draft, that it does only id/idref.

Decision by: xpath-tf on 2002-05-07 ([link to member only information] ) Verifying that the text that the text is in the draft. Note: there is also a proposal on the table to remove => entirely.

Actual Resolution

Decision by: xquery on 2002-05-16 ([link to member only information] )

We will keep the dereference operator.

Actual Resolution

Decision by: xquery on 2002-05-22 ([link to member only information] )

The XML Query WG revisited issue 134 and decided to close the issue by removing => completely. This was not unanimous decision.

Decision by: xsl on 2002-05-23 ([link to member only information] )The XSL WG agrees with the change to remove =>.

143. xquery-literal-xml-constructor: XML Constructor

Locus: algebra Cluster: constructor-syntax Status: unassigned
Originator: Jonathan Robie

Description

Is there a need for a constructor that creates an instance of the XML Query Data Model from a string that contains XML text?

Proposed Resolution

Close the issue, pending convincing use cases. When do we need to be able to create a string of XML text, then convert it into an instance of the XML data model? Can't there always be an intervening parser or other tool to create the XML data model instance?

144. xquery-escaping-quotes-and-apostrophes: Escaping Quotes and Apostrophes

Locus: xquery Cluster: syntax Status: decided
Originator: XML Query

Description

In attribute constructors and string constructors, XQuery uses quotes or apostrophes as delimiters. How are these characters escaped when they occur within strings that are created by one of these constructors?

Proposed Resolution

I propose that we use double-delimiters within a string literal, e.g. 'I don''t', and unlike most of my syntactic ideas, this proposal seemed to recieve general support.

Actual Resolution

Decision by: xpath-tf on 2002-04-30 ([link to member only information] )

Decision by: xquery on 2002-05-22 ([link to member only information] )

Decision by: xsl on 2002-06-27 ([link to member only information] )

Syntax in current draft has this, but explanatory text need to be added.

145. xquery-copy-reference: Copy and Reference Semantics

Locus: xquery Cluster: constructor-expr Status: unassigned
Originator: XQuery Editors

Description

Copy and reference semantics must be defined properly for updates to work. This must be coordinated with the algebra team.

146. xquery-document-construction:

Locus: xquery Cluster: constructor-expr Status: decided
Originator: Jonathan

Description

Can a query construct an entire XML document? What restrictions are there, eg on the internal subset, processing instructions or comments on the root level?

Proposed Resolution

The constructor we propose does nothing except create a document node,
and is very simple. The documents constructed in this way can be
validated, fed to functions that save them or send them as messages,
or used in any other way that document nodes may be used in XQuery.

Currently, we can construct any node in our data model except for the
document node. For instance, we have the following constructors for
element and attribute nodes:

[66] ComputedElementConstructor
    ::=  "element" (QName |  EnclosedExpr) "{" ExprSequence? "}"

[67] ComputedAttributeConstructor
    ::=  "attribute" (QName |  EnclosedExpr) "{" ExprSequence? "}"

We propose an analogous syntax for document nodes, except that there
is no need to create the QName for a document node, which does not
have one:

   DocumentNode ::= 'document' '{' ExprSequence '}'

A document node constructor creates a document node. It does nothing
else. It does not associate the document node with a schema or DTD,
specify a file name for it, validate the instance, assign file
permissions, or shine shoes.


Appendix: Interesting things that are not part of document node
construction

Here are many things people want to do with documents. None of these
are part of document node construction, but all of these things
benefit from document nodes.

1. Validating a node

Once created, a document may be validated, eg:

   let $d := document {
                <?xml version="1.0"?>
                <greeting>Hello, world!</greeting>
           }
   return validate($d)

2. Saving a node to the file system

This is best done using a function that specifies the URI, and any
other parameters that the system may need. The signature for such a
function may look like this:

    save-document( document $docnode, anyURI $name, element file-params? $p)

The file-params element could be used to store information on file
permissions, etc.

Appendix: Issues

Issue: How should schemas be imported for validating a document using
the document node?

Consider the following example:

  <stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
             xmlns:html="http://www.w3.org/1999/xhtml"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.w3.org/1999/XSL/Transform
                                 http://www.w3.org/1999/XSL/Transform.xsd
                                 http://www.w3.org/1999/xhtml
                                 http://example.org/xhtml.xsd">

I think this is no different from validating an element node. A root
element may identify namespace prefixes. Names must be defined in the
in-scope schema definitions before they can be used for
validation. With or without the document node, a schema location may
be specified on an element. Implementations should be free to use this
location to locate a schema or to ignore it, as in XML Schema.

Issue: Should we allow a DOCTYPE in a document constructor?

Consider the following example:

   let $d := document {
               <?xml version="1.0"?>
                <!DOCTYPE greeting SYSTEM "hello.dtd">
                <greeting>Hello, world!</greeting>
             }
   return validate($d)

If a DOCTYPE is specified, should it be used, as it would be by most
XML processors?

Actual Resolution

Decision by: xquery on 2002-05-16 ([link to member only information] )

Cotton: Any objections to adopting this proposal as written by Jonathan? One objection by Michael Rys. Proposal is adopted with one objection.

151. xquery-cut-and-paste-xml: Cutting and pasting XML into XQuery

Locus: xquery Cluster: literal-XML Status: unassigned
Originator: XQuery Editors

Description

A variety of XML constructs can not be cut and paste into XQuery, including the internal subset, entities, notations, etc. Should we attempt to ameliorate this?

152. xquery-abql: XML-based Syntax

Locus: xqueryx Cluster: xqueryx Status: active
Originator: XML Query WG

Description

XQuery needs an XML representation that reflects the structure of an XQuery query. Drafts of such a representation have been prepared, but it is not yet ready for publication.

153. xquery-escape-to-abql: Escape between syntaxes

Locus: xquery Cluster: xqueryx Status: active
Originator: Jerome Simeon

Description

Is there a need to be able to escape to ABQL in XQueryX?

The text is confused. ABQL was the old name of XQueryX. The real issue is should be whether XQueryX and XQuery can escape to each other.

155. xquery-phantom-sortby: Sorting by Non-exposed Data

Locus: xquery Cluster: sort Status: unassigned
Originator: Michael Rys

Description

Should we make it easier to sort by data that is not exposed in the result? Although the current language allows this, it is difficult to define complex sort orders in which some items are not exposed in the result and others are computed in the expression that is sorted. Is there a more convenient syntax for this that would be useful in XQuery?

Interactions and Input

Cf. Add 'order by' clause to FLWR?

Proposed Resolution

Here is an example:

FOR $e IN //employee
WHERE ...
RETURN
  <newe>$e/name</newe>
SORTBY
  -- Now I would like to sort by salary but cannot.

Instead, the query would have to be written as

FOR $e IN (FOR $x IN //employee RETURN $x SORTBY employee/salary/data())
WHERE ...
RETURN
  <newe>$e/name</newe>

Which seems awkward.

The question is of course how we can integrate the SORTBY in an other
way.

For example, could we say

FOR $e IN //employee
WHERE ...
SORTBY $e/salary/data()
RETURN
   <newe>$e/name</newe>

?

Best regards
Michael

157. xquery-function-library: Function Libraries

Locus: xquery Cluster: functions Status: unassigned
Originator: XQuery Editors

Description

XQuery needs a mechanism to allow function definitions to be shared by multiple queries. The XQuery grammar allows function definitions to occur without a query expression.

We must provide a way for queries to access functions in libraries. For instance, we might add an IMPORT statement to XQuery, with the URI of the functions to be imported. It must be possible to specify either that (1) local definitions replace the imported definitions, or (2) imported definitions replace the local ones.

160. xquery-naive-implementation: Naive Implementation Strategy

Locus: xquery Cluster: execution-model Status: active
Originator: Marton Nagy

Description

Marton Nagy has suggested that it would be helpful to describe a naive implementation strategy for XQuery.

A naive XQuery implementation might parse the query, map it to Algebra syntax, and pass it to an Algebra implementation to request type checking from the algebra, returning an error if there were static type errors. A naive implementation might then request query execution from the algebra, get the results from the algebra and return it to the user.

Alternatively, the implementation might have its own algebra for execution, or it might generate statements in a specific implementation language such as XPath or SQL.We expect a wide variety of implementation approaches to be used in practice.

163. xquery-filter-typing: Typing of Filter

Locus: algebra Cluster: filter Status: unassigned
Assigned to: Jerome Simeon Originator: Jerome Simeon

Description

The current mapping of filter to the algebra does not preserve much useful type information. Can the mapping be improved? Is there another approach to filter that would yield better type information?

164. xquery-updates: Updates

Locus: xquery Cluster: updates Status: unassigned
Assigned to: Jonathan Originator: XQuery Editors

Description

We believe that a syntax for update would be extremely useful, allowing inserts, updates, and deletion. This might best be added as a non-normative appendix to the syntax proposal, since the algebra is not designed for defining this portion of the language.

166. xquery-exclude-undesireables: Excluding Undesired Elements

Locus: xquery Cluster: miscellaneous Status: unassigned
Originator: Don Chamberlin

Description

How do we exclude undesired elements from the results of joins?

Interactions and Input

[link to member only information] :

168. xquery-groupby: GROUPBY

Locus: xquery Cluster: groupby Status: unassigned
Originator: XML Query

Description

Does XQuery need an explicit GROUPBY expression? This would not add expressive power, but would be convenient, and may be easier to optimize.

169. xquery-conformance: Missing conformance section

Locus: xquery Cluster: conformance Status: unassigned
Originator: Jonathan

Description

The final XQuery recommendation must have a conformance section. The XML Query Working Group has not yet decided what should go into this section.

170. xquery-collections: Document collections

Issue Class: D Locus: xquery Cluster: documents Status: unassigned
Originator: XQuery WG

Description

How are collections of documents named and addressed in queries? How are they associated with files in directory structures, or resources in various systems? How does one address documents within collections?

172. functions-with-implicit-mapping: Some functions taking node sequences and implicitly map?

Issue Class: T Locus: xpath Cluster: typed-value/data() Status: active
Originator: XPath TF

Description

Should small set of functions on nodes, i.e., data(), name, uri-namespace(), be defined on node sequences and have an implicit mapping semantics?, e.g., data(a/b)

Interactions and Input

Cf. Accessing Element Data

177. functions-with-boolean-argument: Consistency of functions that take boolean formal argument

Issue Class: TF Locus: xpath Cluster: choice-context Status: active
Originator: XPath-TF

Description

The proposal by Michael Rys in [link to member only information: Proposal to close issue expr[nodes]] treats not()/not3() differently from all other functions that take a boolean formal argument.

Interactions and Input

Cf. Implicit conversion of node-sets to boolean for comparisons.

180. functions-complex-valued-arguments: Functions expecting complex-valued arguments

Locus: xpath Cluster: functions Status: active
Originator: XPath-TF

Description

Semantics of function application for functions that expect complex-valued arguments is not documented in current WDs.

183. text-nodes-lexical-typed: Text nodes - lexical structure and typed form

Issue Class: T Locus: xpath Cluster: text-nodes Status: active
Originator: XPath TF

Description

Lexical structure and typed form of text nodes discussed in datamodel. No analogous discussion in the XPath document on that there are two ways to access information, as typed content or as nodes. This also needs to be discussed in conjunction with construction.

184. kind-tests: Need ability to test for Comments, PIs

Issue Class: T Locus: xpath Cluster: node-types Status: decided
Assigned to: xquery Originator: F&O TF

Description

Need to extend languages to test for instance-of comments, pis, etc.

Actual Resolution

Decision by: xsl on 2002-06-27 ([link to member only information] )

Decision by: xquery on 2002-07-17 ([link to member only information] )

The issue is "dead", in the sense that the April draft contains text that everyone is happy with.

185. always-explicit-cast: Always explicit cast?

Locus: xpath Cluster: type exception Status: decided
Originator: Phil Wadler

Description

Should we do explicit casts rather than type conversion, like for example Python? This would result in e.g. forceing the user to tag a string everytime...

Interactions and Input

Cf. Support for UnknownSimpleType

Actual Resolution

Addressed by the "Named Typing" proposal.

186. order-union-intersect-except: Ordering of result of union, intersect, and except operators

Locus: xpath Cluster: node order Status: decided
Originator: XPath Editors

Description

What should be the ordering of the results of the union, intersect, and except operators?

Issue is for material in sec 2.4. in Working Draft 2001-11-28.

Proposed Resolution

Union, intersect, and except on node sequences are defined to return their results in document order.

Actual Resolution

Decision by: xsl on 2002-06-27 ([link to member only information] )

Decision by: xquery on 2002-07-17 ([link to member only information] )

The issue is "dead", in the sense that the April draft contains text that everyone is happy with.

187. date-time-operators: Operations supported on date/time types

Locus: xfo Cluster: operators Status: active
Originator: XPath Editors

Description

What arithmetic operations should be supported on date/time types?

Issue is for material in sec 2.5. in Working Draft 2001-11-28.

Actual Resolution

Decision by: xquery on 2002-02-06 ([link to member only information] )

Locus should be Functiond and Operators

189. operators-consistent-f_o: Supported combinations of types for comparison operators

Locus: xpath Cluster: operators Status: active
Originator: XPath Editors

Description

Make sure that the XPath/XQuery document is consistent with the F&O document with respect to the supported combinations of types for comparison operators.

Issue is for material in sec 2.6. in Working Draft 2001-11-28.

191. whitespace-in-element-constructors: Whitespace handling in element constructors

Locus: xquery Cluster: whitespace Status: active
Originator: XPath Editors

Description

How is whitespace handled in element constructors?

Issue is for material in sec 2.8. in Working Draft 2001-11-28.

Interactions and Input

[link to member only information] Michael Kay:

The XQuery WG requested information from XSL WG
as to how we currently deal with whitespace, in the hope that we can provide
an off-the-shelf solution to the problem.

In response to the action, here's a description of what XSLT does.

The stylesheet is an XML document. In constructing its infoset, all
processing instructions, comments, and whitespace-only text nodes are
discarded. (To be absolutely precise, PIs and comments are discarded; then
adjacent text nodes are merged; then whitespace-only text nodes are removed
from the tree). Whitespace text nodes are retained however, in two
circumstances: (a) if the whitespace text node is a child of an <xsl:text>
element, and (b) if an ancestor element specifies xml:space="preserve".

Certain elements in the stylesheet (for example, xsl:element) contain a
"content constructor". A content constructor is a sequence of XSLT
instructions, literal result elements, and literal text nodes. In evaluating
a content constructor, XSLT instructions do whatever the semantics of the
particular instruction say, while literal result elements and literal text
nodes are copied to the result tree.

The effect of this is that a whitespace-only text node in the stylesheet is
copied to the result tree only if either (a) it appears immediately inside
<xsl:text>, or (b) it is within the scope of an xml:space="preserve"
attribute.

Whitespace that is adjacent to non-white text in a literal text node is
copied to the result tree.

The effect of these rules is as follows:

=======================================
<a>  </a>
generates an empty element:
<a/>
=======================================
<a xml-space="preserve">  </a>
generates:
<a xml-space="preserve">  </a>
=======================================
<a><xsl:text>  </xsl:text></a>
generates:
<a>  </a>
=======================================
<a>
  <b/>
<a>
generates:
<a><b/></a>
=======================================
<a>Some text
  <b/>
</a>
generates:
<a>Some text
  <b/></a>
=======================================

There are other complications with whitespace. Whitespace in the result tree
can come from the source document as well as from the stylesheet; XSLT
provides control over whether whitespace-only text nodes in the source
document are significant or not. Whitespace can also be generated in the
output during serialization, if the xsl:output option indent="yes" is
specified.

Also of course the XSLT rules apply in addition to the XML rules. XML for
example normalizes line endings and normalizes whitespace (but not 

character references) in attribute values. This happens outside XSLT's
control. Whitespace character references such as   are treated
differently from literal whitespace by the XML processor, but are treated
identically to literal whitespace by the XSLT processor.

It's fair to say that these rules create a fair bit of confusion. It usually
doesn't matter for generating HTML, because whitespace in HTML is rarely
significant. For generating text files, it can be quite tricky. However, the
rules are well-defined and a user who understands the rules can always get
the required output.

What should XQuery do? I'd suggest mimicking these rules as closely as
possible, if only because users then only have to learn one set of confusing
rules rather than two. I can't think of any obvious improvements that would
make the system less confusing. Where the user wants to explicitly output
whitespace, of course, <a>{'  '}</a> provides a suitable alternative to
XSLT's <xsl:text> instruction.

This analogy would suggest that <a>  {'x'}  </a> should output <a>x</a>,
while <a>z {'x'} y</a> should output <a>z x y</a>: that is, the characters
between <a> and "{" are ignored if they consist entirely of whitespace, but
are all significant if any of them is non-whitespace. <a> </a> should output
<a/>, as should <a> </a>. This is only a suggestion, of course, the
decision is entirely for XQuery to make.

Mike Kay

192. type-of-constructed-element: Type of a newly constructed element

Issue Class: T Locus: xquery Cluster: type constructed element Status: decided
Originator: XPath Editors

Description

What is the type of a newly constructed element?

Issue is for material in sec 2.8. in Working Draft 2001-11-28.

Interactions and Input

Cf. Is the QName denoting type information optional or required?

Cf. Should all elements and attributes have type annotations?

Actual Resolution

Addressed by the "Named Typing" proposal.

193. non-valid-xml-construction: Construction of non representable XML

Issue Class: T Locus: xquery Cluster: xml non representable Status: active
Originator: XPath Editors

Description

An element constructor may contain adjacent simple values as the content of the element. This cannot be represented in XML. What should we do about this?

Issue is for material in sec 2.8. in Working Draft 2001-11-28.

195. sort-heterogenous-sequence: Semantics of sorting heterogeneous sequences

Locus: xquery Cluster: sort Status: active
Originator: XPath Editors

Description

Is it possible to sort a heterogeneous sequence? What syntax and semantics are used?

Issue is for material in sec 2.10. in Working Draft 2001-11-28.

196. syntaqx-datatype-declarations: Concrete syntax for datatype declarations

Issue Class: T Locus: xpath Cluster: types Status: decided
Assigned to: xquery Originator: XPath Editors

Description

What should be the concrete syntax for datatypes in function signatures and expressions? Should this syntax support node-or-value? Processing-instructions? Comments? Note that some functions in the F&O document (such as "exists") require "node-or-value" parameters.

Issue is for material in sec 2.13. in Working Draft 2001-11-28.

Actual Resolution

Addressed by the "Named Typing" proposal in SequenceType production.

Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.

Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification.

197. type-on-attributes: Need "attribute of type"?

Issue Class: T Locus: xpath Cluster: types Status: decided
Assigned to: xquery Originator: XPath Editors

Description

The current Datatype production supports declarations of the form "element of type <var>". Do we also need declarations of the form "attribute of type <var>" or "node of type <var>"?

Issue is for material in sec 2.13. in Working Draft 2001-11-28.

Actual Resolution

Addressed by the "Named Typing" proposal in SequenceType production.

Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.

Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification.

198. named-typing-support: Syntax for named typing

Issue Class: T Locus: xpath Cluster: types Status: decided
Assigned to: xquery Originator: XPath Editors

Description

Does the Datatype declaration need a way to specify both the QName of an element or attribute and its type, eg element person of type plumber?

Issue is for material in sec 2.13. in Working Draft 2001-11-28.

Actual Resolution

Addressed by the "Named Typing" proposal in SequenceType production.

Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.

Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification.

199. support-locally-declared-types: Support for locally declared types?

Issue Class: T Locus: xpath Cluster: types Status: decided
Assigned to: xquery Originator: XPath Editors

Description

Should XQuery support the import of locally declared types from schemas?

Issue is for material in sec 2.13. in Working Draft 2001-11-28.

Actual Resolution

Addressed by the "Named Typing" proposal in SequenceType production.

Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.

Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification.

200. semantics-of-only: Semantics of "only"

Issue Class: T Locus: xpath Cluster: types Status: active
Assigned to: xquery Originator: XPath Editors

Description

The keyword "only" remains in the syntax of "instance of", but the meaning of this keyword is not clear. Do we need this? If so, what are its semantics?

Issue is for material in sec 2.13. in Working Draft 2001-11-28.

Further input from Phil Wadler: Suggest we remove "only" from the text, and turn it into an issue. (As noted in the text, "only" makes sense only if we have named types, which is another issue.) If we do have "only", it should be used consistently in both "instance of" and in the "case" of a type switch. [!]

206. xpath-datatype-support: Typing support in XPath

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: Mike Kay

Description

Which of these type productions (CAST, TREAT, ASSERT, TYPESWITCH...) belong in XPath? (ie common to XQuery and XPath)

207. variable-names: Variable names: QNames or NCnames?

Locus: xpath Cluster: variables Status: decided
Originator: Ashok Malhotra

Description

Should variable names be QNames or NCNames? Note that XPath 1.0 uses QNames, and it may be helpful to disambiguate variable names from different modules.

Actual Resolution

Decision by: xsl on 2002-06-27 ([link to member only information] )

Decision by: xquery on 2002-07-17 ([link to member only information] )

The issue is "dead", in the sense that the April draft contains text that everyone is happy with.

208. multiple-curly-braces: Multiple curly braces allowed?

Locus: xquery Cluster: syntax curly brace Status: active
Assigned to: xquery Originator: Phil Wadler

Description

Can you have multiple matching curly braces inside an attribute value? How is it evaluated? What is the associated typing? Note that the BNF permits this.

210. order-sequences: Order of sequences

Locus: xpath Cluster: order sequences Status: active
Originator: Phil Wadler

Description

2.10, * Points 1 and 2 (Draft 2001-11-28). We could specify that lexical order is used when the ordering expression yields a sequence of values. This could be quite useful, e.g., if we represent Section 1.2.3 by (1,2,3) and Section 1.4 by (1,4), then lexical ordering does the right thing. This also implies that () should sort before everything else, as that is what happens with lexical order.

211. treat-choice: Treat and structural vs named typing

Issue Class: T Locus: xpath Cluster: types Status: decided
Assigned to: xquery Originator: Phil Wadler

Description

2.13.2 (Draft 2001-11-28) The behaviour of treat is profoundly affected by the choice between structural and named typing. If we use structural typing, then treat changes the type but not the value; if we use named typing, then treat must return a new value containing the appropriate type names. (Similarly for type switch.) The current wording is vague on this point. Should we be less vague and more clear about what the two different choices involve?

Actual Resolution

Addressed by the "Named Typing" proposal in SequenceType production.

Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.

Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification.

212. datatype-production-name: Is "datatype" a suitable production name?

Locus: xpath Cluster: syntax Status: decided
Assigned to: xquery Originator: Phil Wadler

Description

Is Datatype the right name for production [54] (Draft 2001-11-28)? It may be confused with XML Schema Type 2.

Actual Resolution

Decision by: xsl on 2002-06-27 ([link to member only information] )

Decision by: xquery on 2002-07-17 ([link to member only information] )

The issue is "dead", in the sense that the April draft contains text that everyone is happy with.

213. syntax-special-characters: How to get quotes etc in string literals?

Locus: xpath Cluster: syntax quotes Status: active
Originator: Andrew Eisenberg

Description

How do you get strings such as single and double quote to be allowed in character strings?

      <name>Ben &amp; Jerry&apos;s</name>
  

eg should doubling a quote escape it?

It would seem that we need to allow these CharRef's in string literals as well.

Interactions and Input

Cf. Strings in attributes

214. strings-in-attributes: Strings in attributes

Locus: xquery Cluster: syntax strings in attributes Status: active
Assigned to: xquery Originator: Andrew Eisenberg

Description

Behavior of strings between quotes in attributes is different from that in string literals - should they be unified?

Interactions and Input

Cf. How to get quotes etc in string literals?

215. quantified-expressions-2-or-3-valued: Should we have a 3-valued form of quantifiers?

Locus: xpath Cluster: 3-value-logic Status: active
Originator: Andrew Eisenberg

Description

Should we have a 3-valued form of quantifiers?

QuantifiedExpr is defined as being two-valued, while SQL's is 3-valued. SQL would evaluate 5 >ALL (6, null, 7) as UNKNOWN. XQuery would return FALSE where SQL returns UNKNOWN.

217. focus-context-document: Context document in focus

Locus: xpath Cluster: focus Status: decided
Originator: Michael Rys

Description

The current definition of context documents may be difficult to implement in an efficient manner. Should this definition be simplified? Is this definition needed at all?

Actual Resolution

Decision by: xpath-tf on 2002-07-29 ([link to member only information] )

Decision by: xquery on 2002-07-30 ([link to member only information] )joint f2f, decision missing from minutes confirmed

Decision by: xsl on 2002-07-30 ([link to member only information] )joint f2f, decision missing from minutes confirmed

The definition of context document has been removed.

218. wildcards-for-what: What wildcards; namespaceprefix?

Locus: xpath Cluster: wildcards Status: active
Assigned to: xquery Originator: Michael Rys

Description

Do we need wildcards for only elements and attributes whose namespace URI is null? Are there other wildcards that should be supported?

219. namespaces-context: Context: namespaces

Locus: xquery Cluster: namespaces Status: active
Originator: Michael Rys

Description

XQuery must specify how namespaces are handled in the context.

Note that:

1. An unprefixed element name used as a nametest in a query has the namespaceURI associated with the default element namespace from the context.

Note: we may decide that this is the same as the default namespace of the in-scope namespaces, but this is not certain.

2. An unprefixed attribute has a null namespaceURI

220. document-order-explict-sort: Should there be a way to explicitly sort in document order?

Locus: xpath Cluster: sort Status: active
Originator: Michael Rys

Description

Should there be a way to explicitly sort in document order?

222. namespace-redefinition: Allow redefinition of namespace prefixes?

Locus: xquery Cluster: namespaces Status: active
Originator: Michael Rys

Description

Should we allow redefinition of namespace prefixes using NAMESPACE declarations in order to allow query system defaults that can be overridden by user? What are the interoperability issues of this?

223. external-function-definition: We need a way to declare external functions

Locus: xquery Cluster: functions external Status: active
Originator: Michael Rys

Description

Should we allow external functions to be defined using a syntax like this?

       [71a] ExternalFnDef ::= {"define" S "external" S "function"}
            QName "(" ParamList? ")" ("returns" Datatype)?
  

Interactions and Input

Cf. XQuery Extension Mechanisms

224. function-return-datatype: Why do we want to allow optional returns and DataType?

Issue Class: T Locus: xquery Cluster: types Status: active
Originator: Michael Rys

Description

Would we prefer a syntax that requires explicit declaration of a general type when a function is to be loosely typed, rather than use the current syntax in which the type is omitted when the function is untyped.

225. variable-definition-error: Variable redefinition allowed?

Locus: xpath Cluster: variables Status: active
Originator: Mike Kay

Description

The binding of a variable in an expression always overrides any in-scope binding of a variable with the same name". In XSLT, it is an error to declare a (local) variable if another local variable with the same name is already in scope. This rule has proved useful in catching many user errors, particularly where users misunderstand the nature of XPath variables and think that a second declaration behaves like an assignment statement. I would prefer it to be an error to declare a variable if a variable of that name is already in scope. Also, the scope of variables has not been defined with very great precision, it's not explicitly clear what

for $i ........return for $i in // X, $j in $i/z return ....

means: which $i does this refer to?

Interactions and Input

Cf. Shadowing of Variables

226. testing-existential-expressions: Existential Expressions

Locus: xpath Cluster: existential expressions Status: active
Originator: Mike Kay

Description

Do we want to require implementations to test all pairs in order to determine if there is an incomparable value? Note that there are three choices: return true if any pair that satisfies the condition is encountered, return error on incomparable, or permit implementations to define what to do if both a true comparison and an incomparable pair are encountered. Should static and dynamic semantics handle this differently?

227. syntax-dereference: Syntax for dereference?

Locus: xpath Cluster: syntax dereference Status: active
Originator: Don Chambrelin

Description

What syntax should be used for dereference? In addition to the => syntax described in the document, here are two alternative approaches: (a) Treat dereferencing as an axis; (b) Simply use id(.) in a general step, with no special syntax.

228. default-namespace-functions: Should we keep the default function namespace, and the xf: namespace?

Locus: xpath Cluster: namespace functions Status: active
Originator: Scott Boag

Description

The question was raised of whether the Query WG and F&O TF have 1) a good rationale for putting built-in functions in a namespace, and 2) a consistent story about how this will relate to default namespace declarations and user-defined functions.

It would seem odd to have to have all user defined functions put in the FandO namespace if a namespace is not declared for it. If you do not do that, then user defined functions that don't require a prefix will not match the QName.

And, if there is not a good rational that provides user benifits, then it seems like we are going through a lot of additional complexity for little or no benefit.

229. more-than-one-precedes: Do we need both << and precedes?

Locus: xpath Cluster: syntax Status: decided
Originator: XQuery/XSL WGs

Description

Do we need both << and precedes?

Actual Resolution

Decision by: xpath-tf on 2002-07-29 ([link to member only information] )

Decision by: xsl on 2002-07-30 ([link to member only information] )(joint meeting)

Decision by: xquery on 2002-07-30 ([link to member only information] )(joint meeting)

"precedes" and "follows" operators deleted.

230. context-multiple-documents: Context document adequate for multiple docuemnts?

Issue Class: D Locus: xpath Cluster: context Status: decided
Originator: Michael Rys

Description

Is "/" and the context document adequate for multiple documents?

Interactions and Input

Cf. Mapping Input Context

Actual Resolution

Decision by: xpath-tf on 2002-07-29 ([link to member only information] )

Decision by: xquery on 2002-07-30 ([link to member only information] )joint f2f, decision missing from minutes confirmed

Decision by: xsl on 2002-07-30 ([link to member only information] )joint f2f, decision missing from minutes confirmed

Access is provided to multiple documents using a different mechanism, specifically the input() and collection() functions.

231. fallback-data-function: data(SimpleValue) is error or no-op?

Locus: xpath Cluster: fallback Status: decided
Originator: XSL WG

Description

What is the result of applying the data() function on a SimpleValue? Is it an error, is it a no-op, or is it a type exception with a fallback?

Actual Resolution

Decision by: xpath-tf on 2001-12-18 ([link to member only information] )

Decision by: xquery on 2001-12-19 ([link to member only information] )

Decision by: xquery on 2002-05-22 ([link to member only information] )Reaffirming the XPath TF telcon 2002-04-30 view.

Decision by: xsl on 2002-06-27 ([link to member only information] )

data() applied to simple value is identity function (no-op). Rationale: does not require special 'fallback' behavior and if we resolve Issue 0172 so that data is defined on node sequences, then for consistency, it should be defined on heterogeneous sequences. Still waiting on general proposal for Issue 172.

At the XPath TF telcon 2002-04-30 it was noted that the current documents do not reflect the resolution, as recorded in our issues list. The documents need to be modified accordingly.

232. operators-on-date: Use "+" and "-" on dates and durations?

Locus: xpath Cluster: syntax operators date Status: active
Originator: Phil Wadler

Description

Should we use the operators + - on dates and durations, when addition of dates is not associative or commutative?

233. syntax-flwr: Simpler FLWR syntax?

Locus: xpath Cluster: syntax Status: active
Originator: Phil Wadler

Description

Now that we have keywords, should we return to the simpler syntax?

  FLWRExpr ::= (ForClause | LetClause | WhereClause)* "return" Expr
  

234. order-sequences-who-defines: Who defines sorting order of ()?

Locus: xpath Cluster: order sequences Status: active
Originator: Phil Wadler

Description

2.10, + Point 5 (Draft 2001-11-28). If we don't adopt Plil W's proposal in Point 1, then there should be an Issue as to whether the behaviour should be specified by the user, or the vendor. One option is to let the user specify that () sorts high, low, or either, in the latter case the vendor decides.

Interactions and Input

Cf. Order of sequences

235. parenthesis-conditional-expression: Need parenthesis in conditional expression?

Locus: xpath Cluster: syntax Status: active
Originator: Phil Wadler

Description

Now that we have keywords, do we need parentheses in the conditional expression?

236. keyword-before-simpletype: SimpleType preceded by a keyword?

Locus: xpath Cluster: syntax Status: active
Assigned to: xquery Originator: Phil Wadler

Description

Issue as to whether SimpleType (was BuiltInType) might be preceded by a keyword. Now that we have "element of type" it seems natural to use "type" to preced SimpleType, possible generalizing to also allow a complex type.

237. parenthesis-type-switch-expression: Need parenthesis in type switch expression?

Locus: xpath Cluster: syntax Status: active
Originator: Phil Wadler

Description

Now that we have keywords, do we need parentheses in the type switch expression?

238. consistency-tradeoffs: Consistency: tradeoff between interoperability and efficiency

Locus: xpath Cluster: consistency Status: active
Originator: Phil Wadler

Description

Consistent tradeoff between interoperability and efficiency. There are a number of places where XQuery must choose between pinning down precise behaviour or offering flexibility to the implementor. These include whether order in "for" expressions is significant, whether sorting is stable, whether order is significant for duplicate elimination, whether order is significant when finding the union, merge, except of sequences of values, and the like. We should have a consistent policy for making these choices.

239. consistency-bracketing: Consistency: bracketing of nested expressions

Locus: xpath Cluster: consistency Status: active
Originator: Phil Wadler

Description

Consistent bracketing of nested expressions. Some nested expressions are surrounded by parentheses (treat, cast, assert), some nested expressions are surrounded by braces (element construction, function body), and some nested expressions are not bracketed (for expression, conditional expression). We should have a consistent policy for bracketing of nested expressions.

240. consistency-parenthesizing-test-expressions: Consistency: parenthesizing test expressions

Locus: xpath Cluster: consistency Status: active
Originator: Phil Wadler

Description

Consistent parenthesizing of test expressions. Some test expressions are surrounded by parentheses (conditional, type switch) and some are not (where). We should have a consistent policy for parenthesizing of test expressions.

241. consistency-keywords: Consistency: keywords

Locus: xpath Cluster: consistency Status: active
Originator: Phil Wadler

Description

Consistent keywords. Some keywords concatenate two words "sortby", "typeswitch", while others are multiple words "element" "of" "type", "cast" "as", "instance" "of". We should have a consistent policy for keywords.

242. sortby-partial-order: Sortby on partially ordered values?

Locus: xquery Cluster: sort Status: active
Originator: Michael Rys

Description

I was unable to find the semantics of what happens of sortby tries to order based on a base type that only has partial order (e.g., Duration). Can we explicitly disallow this?

243. sort-disappearing: Provide an example of sorting "disappearing"

Locus: xpath Cluster: sort Status: active
Originator: Michael Rys

Description

Provide an example of

   (employee sortby data(salary))/name
  

244. cdata-serialization: CDATA sections and serialization

Locus: xquery Cluster: serialization Status: active
Originator: Michael Rys

Description

What are the semantics of CDATA sections in XQuery? Are they preserved in the data model for serialization?

245. curly-braces-in-text: Are {} in text evaluated?

Locus: xquery Cluster: syntax curly brace Status: active
Originator: Michael Rys

Description

In attribute definitions, "{a}" will be interpreted as expression a returning the value for the attribute. Is this also the case for texts in general (inside an element construction)?

246. nested-comments: Nested XQuery comments allowed?

Locus: xquery Cluster: syntax Status: active
Originator: Michael Rys

Description

Nested XQuery comments allowed?

247. namespace-default-affecting: What does default namespace(s) affect?

Locus: xpath Cluster: namespaces Status: active
Originator: XPath TF

Description

What is effect of default namespace declarations on unprefixed QNames that may occur in element constructors, attribute constructors, and name tests (or anywhere else).

In XPath 1.0, in-scope namespace decls effect prefixed QNames, but default namespace decl does not effect unprefixed names in a name test. In XSLT 2.0, we introduced multiple default namespace decls :one for constructed elements, one for names in xpath expressions.

250. declaring-variables-in-prolog: Declaring Variables in Prolog

Locus: xquery Cluster: variables Status: active
Originator: Jonathan Robie

Description

Functions in a function library often need to access the same variables. For instance, a function library that manipulates a grammar may need to use the following variables in many functions:

$grammar := document("xpath-grammar.xml")/g:grammar
$target := "xquery"

One possible syntax for this is:

'define' ''variable' varname ':=' expr

The above production would occur only in the prolog.

251. sort-by: Sorting "input to loop", not the result

Locus: xquery Cluster: sort Status: active
Originator: Phil Wadler

Description

Consider this query:

   for $x in /books/book, $y in /reviews/review
   where $x/isbn = $y/isbn
   return <newbook>{ $x/title, $x/author, $y/reviewer }</newbook>
   sortby isbn

This is an error, since isbn doesn't appear in newbook. (The static type system would catch this error.) What you have to write is

   for $z in
     for $x in book, $y in review
     where $x/isbn = $y/isbn
     return <dummy>{ $x/title, $x/author, $y/reviewer, $x/isbn }</dummy>
     sortby isbn
   return <newbook>{ $z/title, $z/author, $z/reviewer }</newbook>

This is painful.

I think that XQuery should support this syntax, or something similar:

   for $x in book, $y in review
   where $x/isbn = $y/isbn
   sortby $x/isbn
   return <newbook>{ $x/title, $x/author, $y/reviewer }</newbook>

Our plate is full with more important matters just now, but I hope we could fix this before we finalize XQuery.

252. sortby-name: "sort by" rather than "sortby" for consistency?

Locus: xquery Cluster: consistency Status: active
Originator: Phil Wadler

Description

By the way, why is it "sortby"? Since we changed "instanceof" to "instance of", shouldn't we change "sortby" to "sort by"?

253. cast-simple-type-of-node: CAST as simple type of a node type

Issue Class: TF Locus: xpath Cluster: type-semantics Status: decided
Originator: Michael Rys

Description

Given the expression:

cast as xsd:decimal(//element_string [3]) div cast as
xsd:decimal("+1.25000000")

and a type of ELEMENT element_decimal [xsd:string] for the element_string nodes, our current cast rules disallow the cast of the element node to a value, since the above expression would be translated into:

data(cast as xsd:decimal(//element_string [3])) div cast as
xsd:decimal("+1.25000000")

instead of (the user expected):

cast as xsd:decimal(data(//element_string [3])) div cast as
xsd:decimal("+1.25000000")

Could we change the casting rules to allow the above?

We could either add a rule that pushes data() into cast expressions or have a special rule for casting to simple value types that implies applying data() in the casted expression (similar to arithmetic expressions).

Actual Resolution

Addressed by the "Named Typing" proposal: XQuery Section 2.13 cast does data extraction.

Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.

Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification.

254. lexical-details-in-doc: Should the lexical details be in document?

Locus: xpath Cluster: grammar Status: active
Originator: XPath TF

Description

Current grammar documents lexical states and maps directly to tool we use. An alternative is to use an alternative grammar and document lexical states with the tool separately.

255. operators-derived-type: What are the operators on a derived type?

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: Don Chamberlin

Description

User defines a derived type, what operators are inherited by that type. SQL has a concept of distinct type. A distinct type does not inherit the operastors on the base type. XQuery in F&O does the opposite. All operations on the base type are inherited.

Interactions and Input

[link to member only information] Don Chamberlin:

[link to member only information] Don Chamberlin:

256. return-type-collection: What is return type of colections?

Issue Class: D Locus: xpath Cluster: collections Status: active
Originator: XPath TF

Description

MR: Why does collection() return item*. I want document*.

JR: You can specify what you want. You have to accept a URI and what you return is implementation dependent.

SCA: Strawpoll. 5 item*, 3 document*. No one cannot live with item*

Can an implementation provide a more specific return type than item* and still be a conforming implementation?

Some discussion. No consensus.

257. collection-always-return-same: Does collection() always return same result?

Issue Class: D Locus: xpath Cluster: collections Status: active
Originator: XPath TF

Description

Does collection() always return same result for the same URI? The same within the scope of a query/transformation? Are the nodes in the sequence identical?

258. document-nodes-identity: Identity of Document Nodes

Issue Class: D Locus: xpath Cluster: documents Status: active
Originator: Jonathan Robie

Description

Consider the following query:

        if (document("foo.com") == document("foo.com"))
                then <yep/>
                else <nope/>

I would like the following output:

        <yep/>

I think we can achieve this if we say that the URI of a resource is used as its identity. However, one resource can be identified by more than one URI. Suppose that "foo.com/here/there/hi.xml" and "file://c:/temp/limerick-tei.xml" refer to the same resource. What does the following return?

if (document("foo.com/here/there/hi.xml") ==
document("file://c:/temp/limerick-tei.xml"))
        then <yep/>
        else <nope/>

Should we simply use the URI of the parameter to establish identity and say that the two do not match? Should we make the result implementation-dependent?

260. instanceof-implicit-data: Implicit data() on instanceof?

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: Michael Rys

Description

Does expr instance of type define an expected type with type so that data() is implied explicitly on:

let $e := <e xsi:type=?xsd:integer?/>
return
$e instanceof xsd:integer

is that

let $e := <e xsi:type=?xsd:integer?/>
return
  data($e) instanceof xsd:integer

and thus true or false?

This issue is somewhat related to CAST (Issue 253), but since we perform a type test here, I would argue that we should not.

Interactions and Input

Cf. CAST as simple type of a node type

261. attribute-constructor-quoting-rules: Quoting rules in nested expressions in attribute value construction

Locus: xquery Cluster: syntax quotes Status: active
Originator: Michael Rys

Description

We currently say that in a constant string in XQuery, I can do any of the following three to escape quotes (please correct if I am wrong):

A. XQuery rule (works both in XQuery only and XQuery in XML embedding): quotes and double quotes are doubled if they are enclosed inside their own kind.

E.g.,

Lexical              Value in datamodel
'"'                  "
''''                 '
""""                 "
'""'                 ""

B. XML rules (work only in XQuery in XML embedding since XML parser will work:

B1. Use ' when string delimiter is " and viceversa. This of course does not preserve data fidelity, so if the difference between them is important, you will need to use B2.

B2. Entitize

I assume that I cannot do just B, but that I have to use B to get A. E.g., <a foo="&quot;"/> in an XML document is not a valid XQuery and I have to write <a foo="&quot;&quot;"/>

The problem that I have is that I do not know what the rules are for nesting quotes inside XQuery expressions:

What are the rules for:

<foo bar="{fnc1(<baz goo="{fnc2("string arg")}"/>)}"/>

Do I have to double and then triple? Does {} mean that the outside "" become inconsequential?

262. data-on-elements-with-known-complex-type: Definition of data() on elements with known complex type

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: XPath TF

Description

An alternative definition of data() on elements with known complex type:

If $e is an element of an known (complex) type, then data($e) evaluates to the concatenation of $e's text nodes and has UnknownSimpleType.

This definition is appropriate when explicit casts are necessary to convert UnknownSimpleType to other atomic types, i.e., when the basic conversion rules *DO NOT* implicitly convert UnknownSimpleType to other atomic types.

The benefit of this alternative is that a user can always safely apply data() to any node and is guaranteed never to get an error.

263. data-on-elemets-with-unknown-type: Definition of data() on elements with unknown type, whose content may be simple or complex

Issue Class: T Locus: xpath Cluster: type-semantics Status: decided
Originator: XPath TF

Description

The the data() function is only defined on element and attributes with a simple type. The definition of data() on other kinds of nodes or on element and attributes with unknown type is still an open issue.

The corresponding issue in the Formal Semantics document is Issue-108.

Actual Resolution

Decision by: xpath-tf on 2002-04-11 ([link to member only information] )

xf:data(): decided that it should return the error object when applied to document, PI, comment and namespace nodes.

This change should be reflected in the F&O, XPath and Data Model document.

264. variables-shadowing: Shadowing of Variables

Locus: xpath Cluster: variables Status: active
Originator: Michael Kay

Description

XSLT does not allow a local variable to be declared if there is already a local variable in scope with the same name. For example, the following is disallowed:

<xsl:variable name="i" select="0"/>
<xsl:for-each select="item">
  <xsl:variable name="i" select="$i + 1"/>
  <a><xsl:value-of select="$i"/></a>
</xsl:for-each>

This restriction has proved with experience to be a good thing, because users writing a construct such as the one above have almost invariably misunderstood the way variables work in a declarative language; if the construct were allowed, it would not give them the results they expect.

The equivalent XQuery expression is currently allowed:

let $i := 0
for $x in item
   let $i := $i + 1
   return <a>{$i}</a>

XPath 2.0 has no "let" expression, but it can include variable declarations, and these are allowed to shadow each other.

For XSLT users, it seems inconsistent that there should be different rules in XSLT and in XPath. The XSLT 1.0 rule, which makes variable shadowing an error, has proved useful in practice and we recommend that it should be adopted also for XPath 2.0 and XQuery 1.0.

Interactions and Input

Cf. Variable redefinition allowed?

265. lang-inheritance: How do we determine the xml:lang for a node if it inherits xml:lang from a higher-level node?

Locus: xpath-fulltext Cluster: FTTF-xml:lang Status: active
Originator: FTTF

Description

How do we determine the xml:lang for a node if it inherits xml:lang from a higher-level node?

266. lang-sublanguage-support: Do we support the sublanguage portion of xml:lang?

Locus: xpath-fulltext Cluster: FTTF-xml:lang Status: active
Originator: FTTF

Description

Do we support the sublanguage portion of xml:lang? If so, how?

267. validate-syntax-problem: Syntax problems with "validate"

Locus: xpath Cluster: syntax Status: active
Originator: XPath TF

Description

If "validate" is in XPath the "{}" in the syntax conflicts with the current use in XPath. It needs to change to use "()" instead.

268. string-anySImpleTyped-data-behaviour: xsd:string and anySimpleType'd data behave the same?

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: XQuery WG

Description

Should we simplify the relationship between xsd:string and the anySimpleType'd data to have them both behave the same operationally by providing implicit coercions and being type compatible?

Alternate, in some peoples view mutually exclusive, issue:

Should we simplify the relationship between xsd:string and the anySimpleType'd data to have them both behave the same operationally by disallowing implicit coercions on anySimpleType and being type compatible?

269. unknown-keyword-needed: Can we get rid of the unknown keyword

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: XQuery WG

Description

Can we get rid of the unknown keyword?

Interactions and Input

[link to member only information] Michael Rys:

270. typing-coercions-conformance: Typing, coercions, and conformance

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: XQuery WG

Description

One difficulty in designing XQuery is that it must meet the needs of two quite different constituencies:

Convenient: Quickly write queries to explore a large body of data. Works best with implicit coercions and dynamic typing.

Reliable: Solidly engineer queries for web services. Works best with explicit coercions and static typing.

We've already agreed to have two conformance levels, one with dynamic typing and one with static typing. Perhaps the dynamic typing level should have implicit coercions and the explicit typing level should have explicit coercions.

271. heterogenous-union-types-compatibility: Type compatibility of heterogeneous union types

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: XQuery WG

Description

Currently the formal semantics maps arithmetic and comparison operations that have union types as (at least of one of) their argument types to a runtime type switch. This has serious unwanted consequences for "algebraization" of queries and optimization and leads to some surprising static typing results.

Should we make non-promotable union types on such operations a type error instead?

272. external-functions: External Functions

Locus: xpath Cluster: external-functions Status: active
Originator: Michael Kay

Description

The ability to call external functions is an established feature of XSLT 1.0, and is retained in XSLT 2.0. The facility is widely used, and some significant libraries of external functions have been developed by third parties. We made an attempt to standardize language bindings for external functions in the XSLT 1.1 working draft, but this proved highly controversial and has been dropped. The facility remains, however, even though the binding mechanisms remain implementation-defined.

The XPath 2.0 specification continues to tolerate external functions, though it doesn't really acknowledge their existence properly. All we say is that the repertoire of functions that can be called is part of the context.

The issue is: should the function function-available() function be transferred from XSLT to XPath?

This function tests whether a named function is available, and returns true if it is, and false if it isn't. A typical call is:

if  (function-available('my:debug')) then my:debug('Hi!') else ()

This has two implications:

(a) a call on my:debug must not be a static error if the function is not available

(b) the names of functions (and the in-scope namespaces needed to resolve their QNames) must be available at run-time.

Logically the function-available() function has no dependencies on XSLT so it should be transferred to XPath.

273. external-objests: External Objects

Locus: xpath Cluster: external-objects Status: active
Originator: Michael Kay

Description

Part of the strength of external functions is that they can return objects that are outside the scope of the XPath type system. For example, a function library for performing SQL database access may have a function sql:connect() that returns an object representing a database connection. This object may be passed as an argument to calls on other functions in the SQL function library.

The way this is handled in XPath 1.0 is that the XPath specification defines four data-types, and explicitly leaves the host language free to define additional data types. We could probably live with a similar solution for XPath 2.0, but it's a fudge, and I think we ought to try and do better.

Note that the only things you can do with an external object (under the XSLT 1.0 rules) are to assign it to a variable, or pass it as the argument to another function. In practice I think implementations also allow external objects to have additional behavior, for example they might allow conversion to a string when used in a context where a string is required. I think we should leave such behavior implementation-defined rather than saying that it is always an error.

The question arises as to where external objects should fit into the type hierarchy. Should they be a top-level thing at the same level as "sequence", or should they be one level down, along with "node" and "atomic value"? I think it makes most sense to preserve the principle "everything is a sequence", which means that there are now three kinds of item: nodes, atomic values, and external objects.

Handling this rigorously sounds like quite a pervasive change to the spec, but I don't think it's as bad as it seems. I don't think we should add any language features to support external objects, with the possible exception of a keyword "external" in the type syntax so that one can test for it using "instance of". Functions and operators that work on any sequence (for example, count) should treat an external object like any other item in the sequence. Operations that expect nodes will fail if presented with an external object; operations that expect atomic values will also fail, except that implementations may define fallback conversions from external objects to atomic values.

274. text-only-implementations: Text-node-only implementation possible?

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: XSL WG

Description

The current proposed text for XQuery element constructors precludes a "text node only" implementation. Since XSL should have semantics aligned with XQuery a decision needs to be made by the XSL WG as to if this restriction is acceptable to construction in XSLT.

275. xquery-validate-identity: Should validation also check identity constraints?

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: Jonathan Robie

Description

Should validation also check identity constraints? Note that valid identity constraints of partial documents does not imply validity of the document as a whole. The current document says that identity constraints are not checked.

276. xquery-superfluous-xsi_type: Does validation introduce new xsi:type attributes?

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: Jonathan Robie

Description

Does validation introduce new xsi:type attributes, or should xsi:type attributes introduced for validation be removed?

Note: The XPath telcon suggested that we eliminate this issue and simply say that any attributes introduced for the purpose of validation are removed as part of the validate semantics.

277. xquery-add-xsi_type: Should validate introduce xsi:type?

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: Jonathan Robie

Description

Should validate introduce xsi:type to reflect type annotations that are not explicitly stated using an xsi:type in the source document?

The current draft introduces xsi:type to reflect inferred or dynamically computed types.

278. xpath-is-xsi_type-attribute: Does //@xsi:type match an xsi:type attribute?

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: Jonathan Robie

Description

Does //@xsi:type match an xsi:type attribute? Compare to xml:lang, xml:space, xmlns, which are not represented as attributes in the XML Information Set. Note, however, that xsi:type is represented as an attribute in the Infoset. Should we treat it like other special XML attributes in the Data Model?

279. xpath-lightweight-cast: Should there be a lightweight cast?

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: Jonathan Robie

Description

Should there be any provision for a lightweight cast that does not observe facets? Phil Wadler has suggested that 'validate' be used whenever full schema validation is desired, and 'cast' be used as a lightweight validation, which can be used for either simple or complex types, but which does not supply defaults, enforce facets, or check integrity constraints. It may be easier to optimize through cast than through validate, but supporting both constructs may confuse users due to their similarity. He suggests the following syntax for these expressions:

('cast'|'validate') as SequenceType ()
('cast'|'validate') 'in' ContextExpr { Expr }

280. xpath-list-simple-type: Do we need to distinguish atomic simple types and list simple types?

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: Jonathan Robie

Description

XML Schema supports both atomic simple types and list simple types. Do we need to distinguish them in our grammar?

281. xpath-unknown-simple-type: Representing the type name of untyped character data

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: Jonathan Robie

Description

We need a way to represent the type name of untyped character data. In XML Schema, there is no one type that corresponds to this - in strict mode, elements whose content is untyped character data will have the type 'anyType' and attributes whose content is untyped character data will have the type 'anySimpleType', but this interacts in somewhat complex ways with lax and skip validation.

For now, we assume that character data may be associated with a SimpleType whose name is 'xs:unknownSimpleType'. This type does not currently exist in XML Schema, so we must coordinate with them on this issue.

If Schema does not provide a single type to represent untyped character data, we will provide a keyword for it in the ItemType production.

282. xpath-xs_numeric-type: xs:numeric type

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: Jonathan Robie

Description

For our Formal Semantics, it would be very helpful to have a simple type to represent all numerics. For now, we are using the SimpleType name "xs:numeric". In XML Schema terms, this would be a union type. We must coordinate with XML Schema to see if they can support this. If not, we will provide a keyword for numerics in the ItemType production.

283. xpath-document-element-production: Is the DocumentElement syntax production necessary?

Locus: xpath Cluster: syntax-productions Status: active
Originator: Jonathan Robie

Description

Is DocumentElement necessary?

Proposed Resolution

No.

284. xquery-static-named-typing: Static Named Typing

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: Jonathan Robie

Description

The typing must be covered by a static interpretation. If the Formal Semantics encounters difficulties in producing the static semantics, we may need to change the dynamic semantics.

285. type-information-QName: Is the QName denoting type information optional or required?

Issue Class: T Locus: xpath Cluster: type-semantics Status: active
Originator: Phil Wadler

Description

Is the QName that denotes type information in an element or attribute optional or required?

Interactions and Input

Cf. Type of a newly constructed element

Cf. Should all elements and attributes have type annotations?

286. element-construction-vs-streaming: Element Construction vs Streaming

Locus: xquery Cluster: constructor-expr Status: active
Originator: Michael Rys

Description

The element construction rules in 2.8 make efficient streaming of element construction difficult/impossible. For example, we execute the following expression on a stream and serialize the result in a streaming processing (such as XSLT like applications):

<foo>{"foo", "bar", if (expr) then "baz" else <baz/>}</foo>

If expr is true, then this is serialized:

<foo>foo bar baz</foo>

If expr is false, then this is serialized: <foo>foobar<baz/></foo>

The implementation must cache up the "foo" and "bar" strings, just in case a sub-element node is constructed. If not, then I must insert a space between "foo" and "bar". This seems to contradict one of our explicit use scenarios in the XML Query Requirements (section 2.5).

Interactions and Input

Cf. Functional Status of Comma

Cf. Element Constructor Attribute Order

287. functional-status-of-comma: Functional Status of Comma

Locus: xpath Cluster: syntax Status: active
Originator: Michael Rys

Description

Is , a dyadic operator or (, , ,) a polyargument operator? The element construction rules seem to indicate the later, but the document is not clear. If , is a dyadic node-concatenation operation, then it would be more streamable than as an argument separator for the element constructor.

Interactions and Input

Cf. Element Construction vs Streaming

Cf. Element Constructor Attribute Order

288. element-constructor-attribute-order: Element Constructor Attribute Order

Locus: xquery Cluster: constructor-expr Status: active
Originator: Michael Rys

Description

Unlike XSLT, attributes seem to be allowed anywhere which makes streaming implementations impossible. XSLT has the following rule:

"The following are all errors:

* Adding an attribute to an element after children have been added to it; implementations may either signal the error or ignore the attribute."

Example:

let $e := expr
return <a>{<b/>, ($e/@* | $e/*)</a>

XSLT would consider this an error. XQuery does not. This makes streaming impossible (see #element-construction-vs-streaming). Note that while the above query can easily be rewritten, there are cases (e.g. function calls) where the rewrite is not possible.

Interactions and Input

Cf. Element Construction vs Streaming

Cf. Functional Status of Comma

Proposed Resolution

XQuery should allow implementations to disallow attribute nodes that are specified after the first child node in the sequence. It should not allow disregarding them.

289. attribute-value-construction-from-elements: Attribute Value Construction from Elements

Issue Class: T Locus: xquery Cluster: constructor-expr Status: active
Originator: Michael Rys

Description

What does XQuery do if assigning a list of element nodes to an attribute if the type of the attribute is not a list type?

Example:

<book isbn="{$i/booknum}" />:

This query implicitly gets rewritten to: <book isbn="{data($i/booknum)}" />

What happens if there are more than one booknum elements and ISBN is untyped or not a list type?

290. element-attribute-constructor-name-type: Element Attribute Constructor Name Type

Locus: xquery Cluster: constructor-expr Status: active
Originator: Michael Rys

Description

Does the name expression on dynamically computed names in element/attribute constructors be of type QName without implicit cast from string, QName with implicit cast from string, or string?

Proposed Resolution

If the name is constructed by an expression, the expected type is xs:QName. Xs:string is in general implicitly cast to xs:QName (and xs:anyURI).

291. element-construction-anySimpleType-sequence-content: Element Construction anySimpleType Sequence Content

Issue Class: T Locus: xquery Cluster: constructor-expr Status: active
Originator: Michael Rys

Description

The current element construction treats sequences of anySimpleType values different from other simple typed values. This seems inconsistent. The document should make it clear why there is a difference. If there is a reason, is the reason good enough?

292. element-construction-sequence-vs-multi-expr: Element Construction Sequence vs Multi-expr

Locus: xquery Cluster: constructor-expr Status: active
Originator: Michael Rys

Description

Which element construction rules cover

<e>{1, 2}</e>
vs
<e>{1}{2}</e>

293. cdata-charref-semantics: Cdata and CharRef Semantics

Locus: xquery Cluster: Status: active
Originator: Michael Rys

Description

The data model cannot represent CDATA or CharRef, since the Information Set looses this information.

Proposed Resolution

The XQuery document should make it clear that:

1. CDATA sections and CharRefs inside XQueries that are not embedded inside XML (which is what the XQuery document only talks about), are syntactic helps to write queries that otherwise would need entitization (in the case if CDATA sections) or a unicode input device (CharRefs).

2. Implementations can chose to use this information as serialization hints to preserve the CDATA and entitization.

294. type-annotations-on-all-elems-attrs: Should all elements and attributes have type annotations?

Issue Class: T Locus: xquery Cluster: type-semantics Status: active
Originator: Philip Wadler

Description

Should all elements and attributes have type annotations? In particular, should a newly-constructed element or attribute have a generic type annotation such as "anyType", rather than the current proposal in which it has no type annotation at all? (This is largely a cosmetic issue, about whether "anyType" should be denoted by an explicit annotation or by the absence of an annotation.)

Interactions and Input

Cf. Type of a newly constructed element

Cf. Is the QName denoting type information optional or required?

Cf. Should all elements and attributes have type annotations?

295. lexical-representation-of-atomic-values: Lexical Representation of Atomic Values

Locus: xquery Cluster: lexical-representation Status: active
Originator: xquery/xsl f2f

Description

The wording in section 2.8.3 needs to be aligned with Data model and F&O; 'lexical representation' needs to be defined differently and be consistent in XQuery, Datamodel, F&O. It probably needs to be string value (canonical value of integer in W3C Schema has a "." so not appropriate [or we need to have our own definition of the canonical value...]).

296. definition-leading-slash: What is definition of leading "/"?

Locus: xpath Cluster: path-semantics Status: decided
Originator: XQuery Editors

Description

The current Working Drafts are inconsistent in their definition of a leading slash in a path expresion. A consistent definition needs to be developed.

Actual Resolution

Decision by: xpath-tf on 2002-07-29 ([link to member only information] )

Decision by: xquery on 2002-07-30 ([link to member only information] )joint f2f, decision missing from minutes confirmed

Decision by: xsl on 2002-07-30 ([link to member only information] )joint f2f, decision missing from minutes confirmed

Leading "/" on a path expression means "root(self::node())": the root node of the tree containing the context item. Note that self::node() (and therefore leading "/") raises a dynamic error if the context item is not a node.

297. binding: Should XPath have "type binding" in variable?

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: XQuery Editors

Description

The 2002-06-24 grammar introduces the "binding" production. "assert" is removed from both XQuery and XPath. "binding" currently requires reserved words. Should "binding" be in XPath?

Several reasons NOT to include it in XPath:

- grammar

- semantics don't match function call semantics

- rarely useful

- reads oddly for range variables if (some integer $x in (1,2,"fred") satisfies $x=1)

- biggest of all, users are asking us to simplify. We will get a very adverse reaction if we make "for" expressions more complicated.

But it is worrying to have such a big split between XPath and XQuery.

298. name-sequence-of-homogenous-types: Add Schema type names for sequences of homogeneous types?

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: XPath TF

Description

Should we (or ask schema to) add Schema type names for sequences of homogeneous types?

If we add them now and Schema decide to add them later these would be different as the namespace for the type would be different...

299. character-reference-whitespace: Does character reference to whitespace change whitespace handling?

Locus: xquery Cluster: whitespace Status: active
Originator: XPath TF

Description

In the whitespce proposal the treatment of whitespace character reference is different than treatment of literal whitespace (for "compatibility with XSLT/XPath 1.0") and this does not seem to align with XML parsing.

300. sorting-untyped-data: Should sorting of untyped data be prohibited?

Locus: xquery Cluster: sort Status: active
Originator: XPath TF

Description

Should sorting of untyped data be prohibited? This would catch some user errors.

301. basic-xquery-sql-xml-mappings: Supporting SQL/XML mappings in Basic XQuery

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: Jonathan Robie

Description

Must Basic XQuery support the SQL/XML mappings? One of the original purposes for Basic XQuery was support for mapping relational data, but the SQL/XML mappings would not be allowed as data in the current definition of Basic XQuery, because they contain (a) user-derived simple types, and (b) named complex types, which would result in type annotations in our data model. Since SQL/XML is the only proposed standard for relational mappings, do we need to ensure that we support it in Basic XQuery?

302. arbitrary-documents-types: Support for arbitrary XML documents

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: Jonathan Robie

Description

Must it be possible to query arbitrary XML documents with Basic XQuery?

303. scale-down-type-mappings: Define "scale-down" mappings?

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: Jonathan Robie

Description

The Data Model document defines mappings from the PSV Infoset. If we decide it is essential to query arbitrary XML documents with Basic XQuery, should we define interoperable mappings that would create a representation that has no named types other than built-in XML Schema types? For instance, we might state Basic XQuery implementations map user-derived types to the nearest built-in type, do not create type annotations for named complex types.

304. declare-required-conformance-features: Declare required conformance features?

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: Don Chamberlin

Description

Should there be a way to declare in the Query Prolog which conformance features are required for processing a given query?

305. conformance-prerequisites: Schema Import Feature prerequisite for Static Typing Feature?

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: Don Chamberlin

Description

Should the Schema Import Feature be a prerequisite for the Static Typing Feature? Mike Kay has observed that this is not technically necessary.

306. PSVI-Data-Model-mapping-normative: PSVI to Data Model mapping part of normative text?

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: Don Chamberlin

Description

Should the mapping from PSVI to Query Data Model be part of the normative language specification? (The mapping is affected by the presence or absence of the Schema Import Feature).

307. schema-types-from-input-documents: Schema Types from input documents?

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: Don Chamberlin

Description

During the analysis phase, in-scope schema definitions are derived from schemas named in Schema Import clauses.

Should there be additional in-scope schema definitions that are part of the static context? Should there be another set of in-scope schema definitions that are part of the dynamic context? What would that do to static typing? Would this interfere with interoperability?

In particular:

1. Should an environment be allowed to statically predefine schema definitions for a query? This would allow queries on fixed collections or known message types to provide strong type information without forcing users to explicitly import the corresponding schemas.

2. How does type information found dynamically in queried documents affect the query environment?

Does data() dynamically use the type information found in the instances that are queried, even when the types have not been declared in imported schemas? Note that Basic XQuery does not work properly if this is not true, since it must be able to discover the types of elements without importing their definition.

May an instance contain types that have not been imported into the static environment? If we say it may not, then schema imports are needed to query any document that contains types that are not predefined in XQuery.

May documents that are queried have different definitions for the same names? Note that solutions that dynamically load type information from a document into the in-scope schema definitions may try to introduce all such definitions into the static environment, which should cause an error according to our current rules.

Proposed Resolution

If we want Basic XQuery to be able to query documents that have types that are not predefined, then data() must be able to use type information from instances. But if we want to be able to query validated documents that have different schemas this information must not be added to the static environment (or else we must find a way to add more than one schema definition for a given name to the static environment, or say that the static environment is dynamic, or....).

My tentative conclusions:

1. The in-scope schema definitions should be determined statically.

2. data() and many operators must be able to utilize the type information found in a document.

3. As a matter of convenience, it should be possible to import the schemas associated with a single document or with all documents in a collection. For instance, a syntax like the following may be useful:

import schema from collection
"jdbc:datadirect:sqlserver://localhost:1433;database='airports'"

or

import schema from document
"file:///C:/projects/query/requirements/xml-spec.xsd"

4. Implementations should be allowed to implicitly import schemas into the environment before executing a query, using any of the approved ways above.

308. type-soundness: Type Soundness

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: Don Chamberlin

Description

The Static Typing Feature is claimed to have a property called "type soundness." However, Dana says she has counterexamples to the claim of type soundness as described in this section (Section 2.4.2.3). (At least sequence type matching breaks TYPE SOUNDNESS so what else breaks it?) We need to examine the claim and make sure it is stated correctly.

309. type-error-value: What should be the type of an error value?

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: Don Chamberlin

Description

What should be the type of an error value? Section 2.4.3 says that it can be one item. Some people think it should be more flexible (any sequence of items), and other people think it should be less flexible (an item of a particular type). Some people think it should be an element with a well-defined structure.

310. type-annotations-child-of-element: Are the children of a newly constructed element typed?

Issue Class: T Locus: xquery Cluster: types Status: active
Originator: Dana F

Description

What happens with the type annotation of the children of a newly constructed element? Type annotation kept or given xs:anyType.

311. whitespace-attribute-constructors: Whitespace and Attribute Constructors

Locus: xquery Cluster: whitespace Status: active
Originator:

Description

Whitespace in an XSLT attribute value template is significant insofar as it survives the XML rules for normalization of attributes. This means that CRLF combinations and tabs are normalized to x20 spaces, unless they are written as XML character references. I think it's an open question whether XQuery wants to emulate the XML attribute normalization rules.

In XSLT,

<foo bar="
   {'x'}
"/>

will produce the result <foo bar=" x "/>

while <foo bar=" "/> produces an element containing an attribute whose value is a single CR character.

If XQuery wants to reproduce this behavior exactly, then it's going to have to reproduce the XML treatment of whitespace as well as the XSLT treatment.

But whether it does so or not, I think Mary is right that

<foo bar=" {'x'} "/>

should produce lt;foo bar=" x "/> and not <foo bar="x"/>. There is a difference between element and attribute constructors: attributes have quotes around them, and this sets a different expectation.

312. list-types: What to do about list types?

Issue Class: T Locus: xquery Cluster: types Status: active
Originator: XQuery WG

Description

Merged section on errors and conformance: What to do about list types?

313. union-types: What to do about union types?

Issue Class: T Locus: xquery Cluster: types Status: active
Originator: XQuery WG

Description

Merged section on errors and conformance: What to do about union types?

314. schema-import-basic-xquery: Partial support for SCHEMA IMPORT in Basic XQuery?

Issue Class: T Locus: xquery Cluster: types Status: active
Originator: XQuery WG

Description

Merged section on errors and conformance: Partial support for SCHEMA IMPORT in Basic XQuery?

315. whitespace-in-names: Whitespace allowed in the name of a variable!

Locus: xpath Cluster: syntax Status: active
Originator: Dana

Description

The current Xquery/Xpath grammar allows a whitespace in between the '$' sign and the rest of the name of the variable. This should be forbidden.

316. cardinality-typed-comparison: Is AnySimpleType = AnySimpleType*?

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: Michael Rys

Description

Given the following function:

define function foo(xs:anySimpleType $x) returns xs:anySimpleType {$x}

and the untyped data

<a a="1"/><a a="2"/><a a="3"/>

should the following be a (static or dyamic) type error or should it work?

foo(/a/@a)

If it should work, what should the following query return?

count(data(<e>1 2</e>))
count(data(<a b="1 2"/>/@b))

Should it be 1 or 2?

Proposed Resolution

anySimpleType is the base type of all the *primitive* XML Schema datatypes.

List and union types are *generated* (my word, Schema uses the word *derived*) from primitive types and thus, not included in anySimpleType. See the extract from the XML Schema datatypes spec below.

"[Definition:] There exists a conceptual datatype, whose name is anySimpleType, that is the simple version of the ur-type definition from [XML Schema Part 1: Structures]. anySimpleType can be considered as the *base type* of all *primitive* types. The *value space* of anySimpleType can be considered to be the *union* of the *value space*s of all *primitive* datatypes."

Thus, the function call above should result in a (static or dynamic, depending on typing conformance) type error.

The count expressions would always return 1.

317. extension-mechanism: XQuery Extension Mechanisms

Locus: xquery Cluster: extensions Status: active
Originator: Andrew Eisenberg

Description

Issue: XQuery has not determined what extension mechanisms might be supported. XQuery may support the following:

  • implementation-defined extensions to the XQuery grammar
  • an XQuery-flagger that identifies extensions to XQuery 1.0
  • implementation-defined extensions to the functions that are available to
  • an XQuery author. The author would be required to explicitly declare the
  • namespaces of any extension functions that are used

Interactions and Input

Cf. We need a way to declare external functions

318. sort-in-FLWR: Add 'order by' clause to FLWR?

Locus: xpath Cluster: sort Status: active
Originator: Jonathan Robie

Description

Four issues were raised in a proposal to restructure sorting in XQuery [1]:

1. Should we add an 'order by' clause to FLWR?

The following syntax has been proposed:

FLWRExpr ::= (ForClause |  LetClause)+ SortClause? WhereClause?
"return"  Expr
OrderClause ::=  "order by" stable? SortSpecList
SortSpecList ::= Expr SortModifier ("," SortSpecList)?
SortModifier ::= ("ascending" |  "descending")? ("empty" "greatest"
|  "empty" "least")?

The OrderClause sorts the tuple stream based on the conditions specified in the SortSpecList.

In the status quo, 'sortby' is a standalone postfix expression. FLWR is used to iterate, and 'sortby' is used to sort. This causes certain difficulties, because iteration and sorting are not distinct, unrelated operations - in general, the order in which the output sequence is ordered determines the best order to choose when iterating over the input.

When sorting data created with element constructors, it can sometimes be quite tricky to determine the original source of data in a constructed element. The more complex the expressions that construct the element, the more tricky this becomes. It is also tricky to iterate in an order determined by data that is not returned in a generated sequence.

If we add this clause, should a FLWOR expression that contains an OrderClause but no ForClause result in a semantic error, since there is no tuple stream to sort?

2. If we add an 'order by' clause, should we keep the sortby() expression, or remove it from our language?

Keeping it is convenient for some expressions. Removing it leaves us with a simpler language, and does not require us to explain to our users why we have two ways of doing the same thing.

3. How should we formalize 'order by' - or should we formalize it in Version 1.0?

The most straightforward way to formalize 'order by' is to use tuples, which do not exist in our Data Model, and these would cause significant change to our Formal Semantics. However, the semantics of 'order by' are straightforward.

Our options seem to be:

3.a. Ensure that we know how it would be formalized using tuples, but postpone including this in the Formal Semantics until after Version 1.

3.b. Refuse to add the feature unless it can be formalized with our current Data Model.

3.c. Restrict the feature to functionality easily formalized with our current Data Model.

I believe there was significant enthusiasm for 3.a. in today's telcon.

4. Is the 'order by' clause part of the XPath spec, or is it only in XQuery?

Jonathan

Interactions and Input

Cf. Sorting by Non-exposed Data

319. namespace-definitions-and-validate: Namespace definitions and in-scope namespaces

Locus: xquery Cluster: namespaces Status: active
Originator: XPath TF

Description

Addition of namespaces in the query prolog to the in-scope namespaces; how is this information carried through to provide input to validation?

Additional aspecs are:

(a) the whole question of how the namesapce context is affected by namespace declarations in element constructors

(b) the general notion (in XQuery, specifically), that the static context can vary for different parts of a query

(c) what information gets through to act as input to validation

320. types-conformancelevels-same-results: Should different conformance levels give the same result for the same query and data?

Issue Class: T Locus: xquery Cluster: types Status: active
Originator: Anders Berglund

Description

Are different conformance levels going to give the same results? Is it possible to get different results for the same query? The principle should be that you either get the same result or a failure. Currently this isn't the case.

Interactions and Input

[link to member only information] Anders Berglund:

[link to member only information] Kristoffer Rose:

Cf. Schema Import, Static Typing: what is interoperable?

Cf. Optional Features vs. Conformance Levels

321. validate-lax-strict: Is validate strict or lax?

Locus: xquery Cluster: validate Status: active
Originator: XSL/XQuery joint

Description

Does "validate" do strict or lax validation?

322. validate-lax-strict-override: "validate" strict/lax override?

Locus: xquery Cluster: validate Status: active
Originator: XSL/XQuery joint

Description

Should the user should be able to override which type (strict/lax) of validation "validate" does?

323. unordered-in-xpath: Should "unordered" be included in XPath?

Locus: xpath Cluster: Status: active
Originator: XSL/XQuery joint

Description

Should "unordered" keyword be included in XPath? It does cause problems with the grammar (keyword issue).

324. variables-external: How can variables be bound external to XQuery itself?

Locus: xquery Cluster: variables Status: active
Originator: XSL/XQuery joint

Description

How can variables be bound external to XQuery itself (e.g. like parameters to the query)?

325. element-def-not-in-in-scope: Refering to element that is not in the in-scope schema def.

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: XQuery

Description

We don't have not any way on our syntax to refer to a "foo" as an element that it's not in the in-scope schema def.

326. require-type-definition: Semantics of element foo of type T

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: XQuery

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.

327. functions-parameter-evaluation:

Locus: xpath Cluster: functions Status: active
Originator: XSL/XQuery joint

Description

Is an implementation obligated to evaluate all its parameters (and raise any errors doing so) even when they're not needed in the function body?

328. cdata-section: What does CDATA section constructor construct?

Locus: xquery Cluster: cdata section Status: active
Originator: Michael Kay

Description

Section 3.7.5 describes CDATA section constructor, but these cannot be represented in the data model.

329. duplicate-attribute-constructors: Duplicate attribute constructors

Locus: xquery Cluster: constructors Status: active
Originator: Michael Kay

Description

If there are multiple constructors for the same attribute on an element; which one is taken or is it an error?

330. some-filter-on-type: Should "some" do type filtering?

Issue Class: T Locus: xquery Cluster: types Status: active
Originator: Michael Kay

Description

Currently "some" doesn't do any filtering, which seems unnatural. We could change the some behaviour to actually do the type filtering.

It is easy to imagine that "some hatsize $h in $seq satisfies $h=3" ignores items in $seq that are not hatsizes. Currently, of course, it causes an error if the sequence might contains things other than hatsizes.

331. static-dynamic-dispatch: Static vs. dynamic dispatch for arithmetics

Issue Class: T Locus: xpath Cluster: types Status: active
Originator: Dana Florescu

Description

The current XPath/XQuery specification, as well as the Formal semantics document, mandate that the specific arithmetic operation to be executed depends on the runtime type of the arguments. For example, the addition of two variables $x and $y will be executed as an integer addition if the dynamic types of the two values are both subtypes of integer, and does not depend on the static type of the variables $x and $y (which may be decimal).

Implementing this semantics requires a runtime dispatch plus an runtime interaction with the type system for subtype testing. This can be very costly. Moreover, this semantics can prohibit other useful compile time optimizations like index utilization.

We may allow implementations to use either a static or dynamic dispatch for arithmetic operations in order to improve performance.

332. schema-import-static-typing-interoperable-results: Schema Import, Static Typing: what is interoperable?

Locus: xpath Cluster: types Status: active
Originator: XPath TF

Description

What interoperability is expected for queries that are executed with and without Schema Import? Does the current text reflect the desired goals?

What interoperability is expected for queries that are executed with and without Static Typing? Does the current text reflect the desired goals?

Interactions and Input

[link to member only information] Phil Wadler:

Cf. Should different conformance levels give the same result for the same query and data?

Cf. Optional Features vs. Conformance Levels

333. optional-features-vs-conformance-levels: Optional Features vs. Conformance Levels

Locus: xpath Cluster: conformance Status: active
Originator: XPath TF

Description

Should "Schema Import" and "Static Typing" be independent, optional features or should there be a layer of conformance levels? For XQuery the latter might be "Basic XQuery", "Basic XQuery" + "Schema Import", and "Basic XQuery" + "Schema Import" + "Static Typing".

Interactions and Input

Cf. Should different conformance levels give the same result for the same query and data?

Cf. Schema Import, Static Typing: what is interoperable?

F Revision Log (Non-Normative)

F.1 16 Aug 2002

  • A new section has been added on Errors and Conformance. All references to the "error value" have been deleted since this value is no longer part of the Data Model.

  • The grammar has been revised to explicitly represent precedence of operators. This grammar change required editorial changes to some parts of the document, including the description of path expressions.

  • The grammar appendix has been reworked, and the use of tokens much reduced. A strong effort has been made to reduce reserved keywords. Lexical recognition is now explained more uniformily for XQuery and XPath, and is represented by lexical state transition tables.

  • A new arithmetic operator, idiv (integer division) has been added.

  • A new prefix operator, unordered, has been added.

  • A new computed constructor has been added for document nodes.

  • The dereference operator (=>) has been deleted.

  • The precedes and follows operators have been deleted.

  • The assert expression has been deleted and replaced by optional type declarations wherever variables are bound. Related changes have been made in the syntax of the typeswitch expression.

  • Definitions of element and attribute constructors, typed value, and validate expressions have been modified. All constructed but unvalidated elements now have the type annotation xs:anyType. More details have been added regarding the handling of whitespace in constructed elements.

  • Definitions of constructor functions and cast expressions have changed. Every built-in type now has a constructor function with the same name as the type. It is now possible to cast to a derived atomic type from xs:string or from any supertype of the derived type (facets are checked during casting).

  • The definition of Effective Boolean Value has been changed to return True for a sequence containing both nodes and atomic values.

  • A new xmlspace declaration has been added to the Query Prolog to control handling of whitespace in element and attribute constructors.

  • A new default collation declaration has been added to the Query Prolog.

  • The rules for Sequence Type Matching have been revised to take into account substitution groups.

  • Minor syntax changes have been made in the Query Prolog and in sort by expressions (sort by is now two words).

  • The keyword unknown in a SequenceType has been changed to untyped.

  • Material has been added on importation of type definitions from input documents.

  • Four predefined namespace prefixes have been added: xml, xs, xsd, and xsi. Also, a default function namespace has been predefined.

  • Examples based on filter and shallow functions have been deleted, since these functions are no longer built-in.

  • The term context document has been removed from the evaluation context. The semantics of path expressions have been described without reference to this term.

  • The grammar no longer supports a sequence of consecutive comparison operators such as a < b < c. This is documented as an incompatibility with XPath 1.0.

  • New arithmetic functions for date/time values have been added to the Operator Mapping Table.

  • An additional XPath incompatibility has been documented: A and B no longer guarantees that B will not be evaluated if A is false.

F.2 10 Apr 2002

  • Grammar of path expressions has been reorganized to conform more closely to description in Formal Semantics.

  • Material has been added on Named Typing, including detailed syntax for SequenceType declaration, explanation of static and dynamic type-checking, and new rules for type-matching in function calls.

  • Explanatory material has been added on typed values, document order, and the error value.

  • Some terminology has been changed for consistency with other documents; for example, "simple value" changed to "atomic value".

  • Some changes have been made to rules for handling untyped data in arithmetic and comparison expressions.

  • A more detailed specification is provided for the static and dynamic semantics of treat and assert.

  • A new section has been added on validate expressions.

  • More details have been provided on the semantics of element and attribute constructors, including their data model representations.

  • A new section has been added on Input Functions, describing the input(), collection(), and document() functions.

  • An Operator Mapping Table has been added (Appendix B.)

  • Quantified expressions now permit multiple variable bindings.

  • The semantics of sortby have changed: all ordering keys must now have the same type, and explicit control is provided over the placement of empty sort keys.

  • The semantics of and, or, and quantified expressions have changed so that an implementation is not forced to evaluate all the operand expressions if it encounters an error or a conclusive result.

  • Union, Intersect, and Except expressions now apply to nodes only, not to atomic values.

  • The definitions of the precedes and follows operators have been made independent of the preceding and following axes, since these axes are not supported in XQuery.

  • The operators == and !== have been changed to is and isnot.

  • Quotes are now required around attribute values in element constructors, even if the value is computed by an enclosed expression.

  • It has been clarified that the result of a dereference operator is a node list in document order without duplicates.

  • It has been clarified that the default element namespace applies to types as well as to elements.

F.3 20 Dec 2001

  • Document had been completely rewritten during the joint work on XPath (see text in Intro).

  • The following issues have been resolved:

    Issue-0028: 3-value-logic

    Should not( () ) == true or () or not3 function be defined?

    Issue-0032: for-expr

    Do we really require for at the XPath expression level?

    Issue-0037: datatypes

    Datatypes... XQuery suggests that XPath 2.0 should have a richer set of datatypes based on the built-in types of XML Schema and the notion of an ordered sequence.

    Issue-0068: context

    Do we need a Context Item to track the "current item" in a for itteration, and, if so, how should it work? How should "." work in relation to it?

    Issue-0070: context

    Does the context include a default namespace declaration?

    Issue-0071: context

    Do we need a datatype names binding in the context?

    Issue-0072: context

    How should qname-to-collation bindings be handled?

    Issue-0088: (in)equality-operators

    Implied existential quantifiers

    Issue-0102: null-issue-functions-on-empty

    Functions on Empty Sequences... What should happen if a function expecting one element is invoked on an empty sequence?

    Issue-0103: function-app

    Functions on Sequences... What should happen if a function expecting one element is invoked on a sequence of more than one element?

    Issue-0107: null-functions-on-sequences-b

    Path iteration... How should the current node be passed to a function in a path-step?

    Issue-0110: syntax

    Should we use is and isnot instead of == and !==.

    Issue-0178: type-conversions

    Semantics of positional predicates in XPath

    Issue-0179: type-conversion

    Function call rules needed