Copyright © 2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
XML is an extremely 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. Because query languages have traditionally been designed for specific kinds of data, most existing proposals for XML query languages are robust for particular types of data sources but weak for other types. This specification describes a query language called XQuery, which is designed to be broadly applicable across all types of XML data sources.
This is a public W3C Working Draft for review by W3C Members and other interested parties. This section describes the status of this document at the time of its publication. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress." A list of current public W3C technical reports can be found at http://www.w3.org/TR/.
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. The current version of this document is the first publicly released Working Draft containing the results of integrating these languages.
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.
Comments on this document should be sent to the W3C XML Query mailing list www-xml-query-comments@w3.org (archived at http://lists.w3.org/Archives/Public/www-xml-query-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).
1 Introduction
2 Expressions
2.1 Basics
2.1.1 Expression Context
2.1.1.1 Static Context
2.1.1.2 Evaluation Context
2.1.2 Type Conversions
2.2 Primary Expressions
2.2.1 Literals
2.2.2 Variables
2.2.3 Parenthesized Expressions
2.2.4 Function Calls
2.2.5 Comments
2.3 Path Expressions
2.3.1 Axis Steps
2.3.1.1 Axes
2.3.1.2 Node Tests
2.3.2 General Steps
2.3.3 Step Qualifiers
2.3.3.1 Predicates
2.3.3.2 Dereferences
2.3.4 Unabbreviated Syntax
2.3.5 Abbreviated Syntax
2.4 Sequence Expressions
2.4.1 Constructing Sequences
2.4.2 Combining Sequences
2.5 Arithmetic Expressions
2.6 Comparison Expressions
2.6.1 Value Comparisons
2.6.2 General Comparisons
2.6.3 Node Comparisons
2.6.4 Order Comparisons
2.7 Logical Expressions
2.8 Constructors
2.8.1 Element Constructors
2.8.2 Computed Element and Attribute Constructors
2.8.3 Other Constructors and Comments
2.9 FLWR Expressions
2.10 Sorting Expressions
2.11 Conditional Expressions
2.12 Quantified Expressions
2.13 Datatypes
2.13.1 Referring to Datatypes
2.13.2 Expressions on Datatypes
3 The Query Prolog
3.1 Namespace Declarations and Schema Imports
3.2 Function Definitions
4 Example Applications
4.1 Filtering
4.2 Joins
4.3 Grouping
4.4 Queries on Sequence
A Complete BNF
A.1 Grammar
A.2 Precedence Order
A.3 Lexical structure
A.3.1 Lexical States
B References
B.1 Normative References
B.2 Non-normative References
B.3 Background References
B.4 Informative Material
C Glossary
D XPath 2.0 and XQuery 1.0 Issues (Non-Normative)
E Revision Log (Non-Normative)
E.1 20 Dec 2001
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 small, easily implementable 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 contains XPath Version 2.0 as a subset. 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:
The XQuery data model defines the information in an XML document that is available to an XQuery processor. The data model is defined in [XQuery 1.0 and XPath 2.0 Data Model].
The static and dynamic semantics of XQuery are formally defined in [XQuery 1.0 Formal Semantics]. This is done by mapping the full XQuery language into a "core" subset for which the semantics is defined. This document is useful for implementors and others who require a rigorous definition of XQuery. [Ed. Note: The current edition of [XQuery 1.0 Formal Semantics] has not incorporated recent language changes; it will be made consistent with this document in its next edition.]
XQuery's type system is based on [XML Schema]. Work is in progress to ensure that the type systems of XQuery, the XQuery Core, and XML Schema are completely aligned.
The library of functions and operators supported by XQuery is defined in [XQuery 1.0 and XPath 2.0 Functions and Operators].
One requirement in [XML Query 1.0 Requirements] is that an XML query language have both a human-readable syntax and an XML-based syntax. The XML-based syntax for XQuery is described in [XQueryX 1.0]. [Ed. Note: The current edition of [XQueryX 1.0] has not incorporated recent language changes; it will be made consistent with this document in its next edition.]
XQuery is a strongly typed language. Rules for assigning types to XQuery expressions are described in [XQuery 1.0 Formal Semantics]. A query may import type definitions from a Schema, according to rules that will be specified in a future edition of [XQuery 1.0 Formal Semantics].
Processing a query involves a static typing phase and a dynamic evaluation phase. The type system of XQuery is sound, in that the value yielded by dynamic evaluation is guaranteed to be an instance of the type assigned by static typing.
At user option, static typing can be disabled. A query that passes type checking will return the same result regardless of whether type checking is enabled or disabled. [Ed. Note: See Issues 41 and 55 for a further discussion of static vs. dynamic semantics.]
XQuery may have multiple conformance levels. There may be a conformance level that does not include static type checking. There may be a conformance level that does not support Schema import or reference of types other than the built-in types. [Ed. Note: See Issue 42 for a further discussion of conformance levels.]
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.
[4] | Expr | ::= | SortExpr
| OrExpr | AndExpr | FLWRExpr | QuantifiedExpr | TypeswitchExpr | IfExpr | GeneralComp | ValueComp | NodeComp | OrderComp | InstanceofExpr | RangeExpr | AdditiveExpr | MultiplicativeExpr | UnionExpr | IntersectExceptExpr | UnaryExpr | CastExpr | Constructor | PathExpr |
Note:
For the grammar productions in the main body of this document, the same Basic EBNF notation is used as in [XML], except that grammar symbols always have initial capital letters. The EBNF contains only non-terminals, and all terminal tokens are expanded for readability. Optional whitespace is not represented. A normative version of the EBNF that includes tokens and token states is presented in the appendix [A Complete BNF].
Note:
The use of a prefix token ":" is allowed on unprefixed QNames to lexically distinguish tokens that are spelled the same as keywords.. For instance, the following is a path expression containing the element names "for", "where", and "return": :for/:where/:return
.
The value of an expression is always a sequence. A sequence is an ordered collection of zero or more items. An item is either a simple value or a node. A simple value consists of a value contained in the value space of one of the primitive datatypes described in [XML Schema], together with a reference to a schema component that describes its type. Schema components are defined in [XQuery 1.0 and XPath 2.0 Data Model]. A node conforms to one of the seven node kinds described in
[XQuery 1.0 and XPath 2.0 Data Model]. Some kinds of nodes have typed values, string values, and names, which can be extracted from the node using accessors. The typed value of a node is a sequence of zero or more simple values. The string value of a node is an instance of the type xs:string
. The name of a node is an instance of the type xs:QName
.
A sequence containing exactly one item is called a singleton sequence. A sequence containing zero items is called an empty sequence.
In this document, the namespace prefix xs:
is considered to be bound to the XML Schema namespace http://www.w3.org/2001/XMLSchema
(described in [XML Schema]), and the prefix xf:
is considered to be bound to the namespace of XPath/XQuery functions and operators, http://www.w3.org/2001/12/xquery-operators
(described in [XQuery 1.0 and XPath 2.0 Functions and Operators]).
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.
The static context of an expression is defined as all 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 on QNames within the expression.
Default namespace for element names. This is a namespace URI. This namespace is used for any unprefixed QName appearing in a position where an element 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 type definitions. This is a set of (QName, type definition) pairs. It defines the set of types that are available for reference within the expression.
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 XPath 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 is a set of (QName, function signature) pairs. It defines the set of functions that are available to be called from within the expression. The QName represents the name of the function, and the function signature specifies the static types of the function parameters and function result.
In-scope collations. This is a set of (QName, 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.
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 four components of the dynamic context (context item, context position, context size, and context document) 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
and the filter expression E1[E2]
, create a new focus for the evaluation of
a sub-expression. In both 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 a simple 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 the expressions E1/E2
or E1[E2]
are 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 position()
.
When the expressions E1/E2
or E1[E2]
are 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 the expressions E1/E2
or E1[E2]
are evaluated,
the context position in the inner focus for an evaluation of E2
is the number
of items in the sequence obtained by evaluating E1
.
The context document
is the document currently being processed. Its value is a node, which is always
a document node. If there is a context node, and if the tree containing the context node has
a document node as its root, then this document node will be the context document. When
an inner focus is created and the context item in the inner focus is not a node,
or is a node belonging to a tree whose root is not a document node,
then the context document in this inner focus will be the
same as the context document in the outer focus.
The context document is returned by the XPath expression "/
", and is
used implicitly as the base for any absolute path expression, as well being used as
input to certain functions such as xf:id
.
[Ed. Note: See Issue 217.]
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 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 a point in time during processing of a query. It can be retrieved by the xf:currentDateTime
function. If invoked multiple times during the execution of a query, this function always returns the same result.
Certain operators, functions, and syntactic constructs expect a value of a particular type to be supplied: this is referred to as a required type. A required type may be specified in the following ways:
In the signature of a function definition
In the description of an operator
In the description of a syntactic construct, such as the test in a conditional expression
The required type may be specified as a simple type, an optional occurrence of a simple type, a sequence of a simple type, or a sequence of nodes. If no required type is specified, the value may be any sequence. If the value supplied does not conform to the required type, it is converted to the required type by applying the basic conversion rules.
In some cases, the basic conversion rules may invoke a type exception. A type exception may be invoked either statically (during query analysis) or dynamically (during query execution). XQuery treats a type exception as an unrecoverable error.
The basic conversion rules are as follows:
If the required type is a simple type or an optional occurrence of a simple type:
If the given value is a sequence of more than one item, a type exception is invoked. If the given value is a single node, its typed value is extracted by calling its typed value accessor. If the node has no typed value accessor or if its typed value is a sequence containing more than one item, a type exception is invoked.
If the (given or extracted) value has an unknown simple type (as in the case of character data in a schemaless document), an attempt is made to cast it to the required simple type. If the cast fails, a type exception is invoked.
If the (given or extracted) value does not conform to the required type, a type exception is raised. This includes the case in which the (given or extracted) value is an empty sequence and the required type is not an optional occurrence.
If the required type is a sequence of a simple type:
If the given value is a sequence containing one or more nodes, each such node is replaced by its typed value, resulting in a sequence of simple values. Each of these simple values then is converted to the required type by applying the rules described above for converting values to a required simple type.
If the required type is a sequence of nodes:
If the given value contains any item that is not a node, a type exception is invoked.
Ed. Note: In order to handle user-defined function signatures, the notion of "required type" must be extended to include the full datatype syntax in 2.13 Datatypes. The basic conversion rules must be extended to deal with complex types. For example, can an element of a given type be used where an element of a supertype is expected? Can an element be used where another element in the same substitution group is expected?
Primary expressions are the basic primitives of the language.
[47] | PrimaryExpr | ::= | Variable
| Literal | ElementNameOrFunctionCall | Wildcard | KindTest | ParenthesizedExpr |
Ed. Note: Wildcard and KindTest are used in path expressions and are described in 2.3.1.2 Node Tests. In the current version of the grammar, they are included as forms of PrimaryExpr for technical reasons. This part of the PrimaryExpr grammar is subject to change. We also expect to separate ElementNameOrFunctionCall into two productions: ElementName, which is a form of abbreviated path expression, and FunctionCall, which is a form of primary expression.
A literal is a direct syntactic representation of a simple value. XQuery supports two kinds of literals: string literals and numeric literals.
[49] | Literal | ::= | NumericLiteral | StringLiteral |
[48] | NumericLiteral | ::= | IntegerLiteral | DecimalLiteral | DoubleLiteral |
[167] | IntegerLiteral | ::= | [0-9]+ |
[168] | DecimalLiteral | ::= | ("." [0-9]+) | ([0-9]+ "." [0-9]*) |
[169] | DoubleLiteral | ::= | (("." [0-9]+) | ([0-9]+ ("." [0-9]*)?)) ([e] | [E]) ([+] | [-])? [0-9]+ |
[180] | 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.
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.
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]. For example:
xf:true()
and xf:false()
return the
boolean values true
and false
, respectively.
xf:integer("12")
returns the integer value twelve.
xf:date("2001-08-25")
returns an
item whose simple type is xs:date
and whose value represents the date 25th
August 2001.
It is also possible to construct values of other built-in types using
the cast
expression.
For example:
cast as xs:positiveInteger(12)
returns a simple value whose primitive value is the decimal value 12.0 and whose type is the built-in derived type xs:positiveInteger
.
A variable evaluates to the value to which the variable's QName is bound in the evaluation context. It is an error if the variable's QName is not defined in the evaluation context. 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.
[158] | Variable | ::= | "$" QName |
Ed. Note: In XQuery this production may end up being constrained to an NCName. See issue 207.
The binding of a variable in an expression
always overrides any in-scope binding of a variable
with the same name. For example,
for $v in (1,2) return for $v in (3,4) return $v
evaluates to (3, 4, 3, 4)
because the definition of $v
in the inner
for
expression overrides the definition of
$v
in the outer for
expression.
Parentheses may be used to enforce a particular evaluation order in expressions that contain multiple operators, as shown in the following example:
The expression (2 + 4) * 5
evaluates to thirty;
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.
Parentheses are also used as delimiters in constructing a sequence, as described in 2.4.1 Constructing Sequences.
A function call consists of a QName followed by a parenthesized list of zero or more expressions. The QName must match the name of an in-scope function in the static context (see 2.1.1 Expression Context). The expressions inside the parentheses provide the arguments of the function call. The number of arguments must equal the number of formal arguments in the function's signature; otherwise an error is raised.
A QName not followed by parentheses is interpreted as an element name, which is a form of abbreviated path expression described in 2.3.5 Abbreviated Syntax.
[51] | ElementNameOrFunctionCall | ::= | QName ("(" (Expr ("," Expr)*)? ")")? |
A function call expression is evaluated as follows:
Each argument expression is evaluated, producing an argument value.
The basic conversion rules are applied for each argument value and its corresponding required type from the function's signature. These rules produce a value of the required type for each function parameter or raise a type exception.
If all argument values can be converted to their corresponding required types, the function is applied to the converted values, and the result of the function call is the result of the function application.
A very common type conversion rule is the
extraction of a simple value from a node. For example, assume that the context node contains an
attribute named color
that contains a string. The
required type of the only argument to
xf:upper-case
is string
. In the function application:
xf:upper-case(@color)
the typed value of the attribute node color
is extracted
before the function is applied.
A large library of functions is defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. Although functions in that document
have the namespace prefix xf
,
this prefix is not required if
the expression context defines a default namespace for the
core library.
The comma operator serves two purposes: it separates actual arguments in a function call, and it separates items in an expression that constructs a sequence (see 2.4.1 Constructing Sequences). To distinguish these two uses, parentheses are used to delimit items in a sequence constructor.
Here are some examples of function calls in which arguments that are literal sequences are delimited with parentheses:
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.
Comments can be used to annotate a query with informative information. Comments are lexical constructs only, and have no meaning within the query.
[77] | ExprComment | ::= | "{--" [^}]* "--}" |
Comments may be used before and after major tokens within expressions and within element content. See A.3 Lexical structure for the exact lexical states where comments are recognized.
Ed. Note: The EBNF here 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.
A path expression locates nodes within a tree, and returns a sequence of distinct nodes in document order. A path expression is always evaluated with respect to an evaluation context. There are two kinds of path expressions: relative and absolute.
[25] | PathExpr | ::= | AbsolutePathExpr | RelativePathExpr |
[31] | AbsolutePathExpr | ::= | ("/" RelativePathExpr?) | ("//" RelativePathExpr) |
[32] | RelativePathExpr | ::= | StepExpr (("/" | "//") StepExpr)* |
[33] | StepExpr | ::= | AxisStep | GeneralStep |
A relative path expression consists of one or more
steps separated by /
or //
. The steps in a relative
path expression are composed together from left to right. Each step in
turn selects a sequence of nodes. An initial
sequence of steps is composed together with a following step as
follows: each node selected by the initial sequence is used to provide a focus for the following step, as described in
2.1.1.2 Evaluation Context. The following step is executed for each such focus, and the resulting sequences of nodes are merged, eliminating duplicate node identities and preserving document order. For example,
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 that have div1
parents.
An absolute path expression consists of /
or //
followed by a relative path expression (if the path begins with /
, the relative path expression is optional.) A /
by itself
selects the root node of the document containing the context node. If
it is followed by a relative path expression, then the path expression
selects the sequence of nodes that would be selected by the relative
path expression relative to the root node of the context document.
The uses of //
in path expressions are examples of abbreviated syntax, explained in 2.3.5 Abbreviated Syntax.
The steps in a path expression are of two general kinds, called axis steps and general steps.
[34] | AxisStep | ::= | (Axis NodeTest StepQualifiers) | AbbreviatedStep |
[35] | Axis | ::= | "child" "::" | "descendant" "::" | "parent" "::" | "attribute" "::" | "self" "::" | "descendant-or-self" "::" |
An axis step begins at the context node, navigates to those nodes that are reachable from the context node via a predefined axis, and selects some subset of the reachable nodes. An axis step has three parts:
an axis, which specifies the relationship between the nodes selected by the axis step and the context node. The axis might be thought of as the "direction of movement" of the axis step.
a node test, which specifies the node type and expanded-name of the nodes selected by the axis step.
zero or more step qualifiers, which further modify the sequence of nodes selected by the axis step.
In the abbreviated syntax for an axis step, the axis can be omitted and other shorthand notations can be used as described in 2.3.5 Abbreviated Syntax.
The unabbreviated syntax for an axis step consists of the axis name and node test
separated by a double colon, followed by zero or more step qualifiers. For example, in
child::para[position()=1]
, child
is the name
of the axis, para
is the node test and
[position()=1]
is a step qualifier.
The node sequence selected by an axis step is found by generating an initial node sequence from the axis and
node test, and then applying each of the step qualifiers
in turn. The initial node sequence consists of the nodes reachable from the
context node via the specified axis that have the node type and
expanded-name specified by the node test. For example, a location step
descendant::para
selects the para
element
descendants of the context node: descendant
specifies
that each node in the initial node sequence must be a descendant of the
context, and para
specifies that each node in the initial
node sequence must be an element named para
. The available
axes are described in 2.3.1.1 Axes. The available node tests
are described in 2.3.1.2 Node Tests. Step qualifiers are described in 2.3.3 Step Qualifiers. Examples of axis steps are provided in 2.3.4 Unabbreviated Syntax
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.
A node test is a condition that must be true for each node selected by an axis step. The condition may be based on the type of the node and/or its name.
[36] | NodeTest | ::= | NameTest | KindTest |
[37] | NameTest | ::= | QName | Wildcard |
[38] | Wildcard | ::= | "*" | ":"? NCName ":" "*" | "*" ":" NCName |
[39] | KindTest | ::= | ProcessingInstructionTest
| CommentTest | TextTest | AnyKindTest |
[40] | ProcessingInstructionTest | ::= | "processing-instruction" "(" StringLiteral? ")" |
[41] | CommentTest | ::= | "comment" "(" ")" |
[42] | TextTest | ::= | "text" "(" ")" |
[43] | AnyKindTest | ::= | "node" "(" ")" |
[Definition: Every axis has a principal node type. If an axis can contain elements, then the principal node type is element; otherwise, it is the type of the nodes that the axis can contain.] Thus:
For the attribute axis, the principal node type is attribute.
For the namespace axis, the principal node type is namespace.
For all other axes, the principal node type is element.
A node test that is a QName
is true if and only if the type of the node (see [XQuery 1.0 and XPath 2.0 Data Model])
is the principal node type 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 will select an empty set of nodes.
attribute::href
selects the href
attribute
of the context node; if the context node has no href
attribute, it will select 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 an 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 type. 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 an 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 type 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 type 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 that has a name equal to the
value of the StringLiteral.
A node test node()
is true for any node of any type
whatsoever.
In addition to the axis step format described above, a step in a path expression may take another form, called a general step.
[44] | GeneralStep | ::= | PrimaryExpr StepQualifiers |
A general step is simply a primary expression, possibly followed by one or more step qualifiers. Since a primary expression may in turn contain any expression in parentheses, a general step may contain any expression.
The expression in the general step must evaluate to a sequence of nodes. The result of the general step is this sequence of nodes, modified by any step qualifiers and sorted if necessary into document order. If the expression in the general step returns any values that are not nodes, an error is raised.
As in the case of an axis step, a general step is executed once if it is the first step in the path expression. If it is not the first step, the general step is executed once for each node selected by the preceding step, using the focus provided by each of these nodes in turn, as described in 2.1.1.2 Evaluation Context. The nodes selected by the general step are then used in turn to provide foci for execution of the following step, if any.
Here are some examples of path expressions that contain general steps:
The path expression in this example begins with a general step that contains a function call. The document
function returns the root node of a document.
document("book3.xml")/descendant::author
This is a three-step path expression in which the second step is a general step that uses the |
operator (see 2.4.2 Combining Sequences.)
child::school/(child::faculty | child::staff)/child::address
Step qualifiers are of two general forms: predicates, which are used to filter a node sequence by applying some test, and dereferences, which are used to map reference-type attribute nodes into the nodes that they reference.
[46] | StepQualifiers | ::= | (("[" Expr "]") | ("=>" NameTest))* |
A predicate consists of an expression, called a predicate expression, enclosed in square brackets. A predicate serves to filter a node sequence, retaining some nodes and discarding others. For each node in the node sequence to be filtered, the predicate expression is evaluated using a focus derived from that node, as described in 2.1.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 nodes 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:
If the value of the predicate expression is an empty sequence, the predicate truth value is false
.
If the value of the predicate expression is one simple value of a numeric type, the value is rounded to an integer using the rules of the round
function, and the predicate truth value is true
if and only if the resulting integer is equal to the value of the context position.
If the value of the predicate expression is one simple value of type Boolean, the predicate truth value is equal to the value of the predicate expression.
If the value of the predicate expression is a sequence containing at least one node, the predicate truth value is true
. Note that the predicate truth value in this case does not depend on the content of the node.
In any other case, an error is raised.
In a sequence of nodes selected by an axis step, the context positions of the nodes are determined in a way that depends on the axis. If the axis is a forward axis, context positions are assigned to the nodes in document order. If the axis is a reverse axis, context positions are assigned to the nodes in reverse document order. In either case, the first context position is 1.
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 dereference operates on a node sequence, mapping element and/or attribute nodes into the nodes that they reference. Every node in the sequence that is input to the dereference must be an element or attribute node whose content is of type IDREF
or IDREFS
; otherwise an error is raised. The dereference generates a new sequence consisting of the element nodes whose ID
-type attribute values match the IDREF
values extracted from the elements and attributes in the input sequence. The resulting sequence is filtered by the NameTest that follows the dereference operator, retaining only nodes whose expanded-names match the expanded-name specified in the NameTest. The filtered sequence of element nodes is then sorted into document order.
Here are some examples of steps that contain dereferences:
This example selects the figure that is referenced by the first figure reference that is a child of the context node:
child::figref[1]/attribute::refid=>figure
This example selects the manager of the manager of the context node, assuming that the context node is an emp
node and that each emp
node has a manager
attribute that references the emp
node of the employee's manager:
attribute::manager=>emp/attribute::manager=>emp
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 2.3.5 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 document root (which is
always the parent of the document element)
/descendant::para
selects all the
para
elements in the same document as the context node
/descendant::olist/child:::item
selects all the
item
elements that have an olist
parent and
that are in the same document as the context node
child::para[position()=1]
selects the first
para
child of the context node
child::para[position()=last()]
selects the last
para
child of the context node
child::para[position()=last()-1]
selects
the last but one para
child of the context node
child::para[position()>1]
selects all
the para
children of the context node other than the
first para
child of the context node
/descendant::figure[position()=42]
selects
the forty-second figure
element in the
document
/child::doc/child::chapter[position()=5]/child::section[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'][position()=5]
selects the fifth para
child of the context node that has
a type
attribute with value
warning
child::para[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][position()=last()]
selects the last
chapter
or appendix
child of the context
node
[45] | AbbreviatedStep | ::= | "." | ".." | ("@" NameTest StepQualifiers) |
The abbreviated syntax permits the following abbreviations:
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
.
There is also an abbreviation for attributes:
attribute::
can be abbreviated to @
. 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
.
//
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.
A step consisting of .
is short for
self::node()
. This is particularly useful in
conjunction with //
. For example, the path expression
.//para
is short for
self::node()/descendant-or-self::node()/child::para
and so will select all para
descendant elements of the
context node.
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[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
//olist/:item
selects all the item
elements in the same document as the context node that have an
olist
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 type
attribute 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 section
element that is a child of the context node.
book/xf:ID(publisher)/name
returns the same
result as xf:ID(book/publisher)/name
.
XQuery supports operators to construct and combine sequences. A sequence is an ordered collection of zero or more items. An item may be a simple value or a node.
[50] | ParenthesizedExpr | ::= | "(" ExprSequence? ")" |
[3] | ExprSequence | ::= | Expr ("," Expr)* |
[17] | RangeExpr | ::= | Expr "to" Expr |
One way to construct a sequence is with a ParenthesizedExpr, which is zero or more expressions separated by the comma (",") operator and delimited by parentheses. A parenthesized expression is evaluated by evaluating each of its constituent expressions and concatenating the resulting sequences, in order, into a single result 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 inside a sequence expression:
(10, 1 to 4)
It evaluates to the sequence:
(10, 1, 2, 3, 4)
[20] | UnionExpr | ::= | Expr ("union" | "|") Expr |
[21] | IntersectExceptExpr | ::= | Expr ("intersect" | "except") Expr |
XQuery provides several operators for combining sequences.
The union
and |
operators are
equivalent.
They take two sequences as operands
and return a sequence containing all the items that occur in either of the operands.
The intersect
operator
takes two sequences as operands and
returns a sequence containing all the items that occur in both operands.
The except
operator
takes two sequences as operands and
returns a sequence containing all the items that occur in the first operand but not
in the second operand.
All of these operators eliminate duplicates from their result sequences. Two nodes are considered to be duplicates if they have the same node identity. Two simple values are considered to be duplicates if they return true
when used as operands of the eq
operator.
In the result sequences returned by these operators, nodes appear in document order, but the order of simple values is implementation-defined.
Here are some examples of expressions that combine sequences.
Assume in the following examples that there are three elements, <a/>
, <b/>
, and <c/>
, and three sequences that contain these elements:
$seq1 = (<a/>, <b/>),
$seq2 = (<a/>, <b/>)
, and
$seq3 = (<b/>, <c/>)
. Then:
$seq1 union $seq1
evaluates to
(<a/>, <b/>)
.
$seq2 union $seq3
evaluates to (<a/>, <b/>, <c/>)
.
$seq1 intersect $seq1
evaluates to (<a/>, <b/>)
.
$seq2 intersect $seq3
evaluates to <b/>
.
$seq1 except $seq2
evaluates to
()
, the empty sequence.
$seq2 except $seq3
evaluates to <a/>
.
The following examples illustrate how sequence-combining operators might be used with sequences of simple values.
(1, 2, 2, 3) union (2, 3, 4)
evaluates to (1, 2, 3, 4)
(1, 2, 2, 3) intersect (2, 3, 4)
evaluates to (2, 3)
(1, 2, 2, 3) except (2, 3, 4)
evaluates to (1)
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.
XQuery provides arithmetic operators for addition, subtraction, multiplication, division, and modulus, in their usual binary and unary forms.
[18] | AdditiveExpr | ::= | Expr ("+" | "-") Expr |
[19] | MultiplicativeExpr | ::= | Expr ( "*" | "div" | "mod") Expr |
[22] | UnaryExpr | ::= | ("-" | "+") Expr |
The binary subtraction operator must be preceded by white space if it follows an NCName, in order to distinguish it from a hyphen, which is a valid name character. For example, a-b
will be interpreted as a single token.
The operands of an arithmetic expression do not have required types. An arithmetic expression is evaluated by applying the following rules, in order, until an error is raised or a value is computed:
If any operand is a sequence of length greater than one, a type exception is raised.
If any operand is an empty sequence, the result is an empty sequence.
If any operand is a node, its typed-value accessor is applied. If the node has no typed-value accessor, or if the typed-value accessor returns a sequence of more than one value, an error is raised. If the typed-value accessor returns the empty sequence, the result of the expression is the empty sequence.
If any operand is an untyped simple value (such as character data in a schemaless document), it is cast to the type suggested by its lexical form. For example, the untyped value 12
is cast to the type xs:integer
.
If the arithmetic expression 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 [XQuery 1.0 and XPath 2.0 Functions and Operators]. 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
.
If the operand type(s) are valid for the given operator, the operator is applied to the operand(s), resulting in either a simple value or an error (for example, an error might result from dividing by zero.) The combinations of simple types that are accepted by the various arithmetic operators, and their respective result types, are listed in [XQuery 1.0 and XPath 2.0 Functions and Operators]. If the operand type(s) are not valid for the given operator, a type exception is raised.
Ed. Note: A future version of this document will provide a mapping from the arithmetic operators to the functions that implement these operators for various datatypes. See issue 182.
Here are some examples of arithmetic expressions:
In general, arithmetic operations on numeric values result in numeric values:
($salary + $bonus) div 12
Subtraction of two dateTime values results in a duration:
$emp/hiredate - $emp/birthdate
Subtracting a duration from a dateTime results in a dateTime:
$paper/deadline - $paper/worktime
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)
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.
[13] | ValueComp | ::= | Expr ("eq" | "ne" | "lt" | "le" | "gt" | "ge") Expr |
[12] | GeneralComp | ::= | Expr ("=" | "!=" | "<" S | "<=" | ">" | ">=") Expr |
[14] | NodeComp | ::= | Expr ("==" | "!==") Expr |
[15] | OrderComp | ::= | Expr ("<<" | ">>" | "precedes" | "follows") Expr |
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. This issue is pending some general grammar issues.]
Value comparisons are intended for comparing single values. The result of a value comparison is defined by applying the following rules, in order:
If either operand is an empty sequence, the result is an empty sequence.
If either operand is a sequence containing more than one item, an error is raised.
If either operand is a node, its typed value is extracted. If the typed value is an empty sequence, the result of the comparison is an empty sequence. If the typed value is a sequence containing more than one item, an error is raised.
If one of the operands is an untyped simple value (such as character data in a schemaless document) and the other operand is a typed simple value, the untyped operand is cast into the type of the other operand. If both of the operands are untyped values, they are both cast to the type xs:string
.
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
. [XQuery 1.0 and XPath 2.0 Functions and Operators] describes which combinations of simple 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 invoked.
Ed. Note: A future version of this document will provide a mapping from the comparison operators to the functions that implement these operators for various datatypes. See issue 182.
Here is an example of a value comparison:
The following comparison is true only if $book1
has a single author subelement and its value is "Kennedy":
$book1/author eq "Kennedy"
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"
The result of a node comparison is defined by applying the following rules, in order:
Both operands must be either a single node or an empty sequence; otherwise an error is raised.
If either operand is an empty sequence, the result of the comparison is an empty sequence.
A comparison with the ==
operator is true
if the two operands are nodes that have the same identity; otherwise it is false
. A comparison with the !==
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.
Here is an example of a node comparison:
The following comparison is true only if the left and right sides each evaluate to exactly the same single node:
//book[isbn="1558604820"] == //book[call="QA76.9 C3845"]
The result of an order comparison is defined by applying the following rules, in order:
Both operands must be either a single node or an empty sequence; otherwise an error is raised.
If either operand is an empty sequence, the result of the comparison is an empty sequence.
A comparison with the <<
operator returns true
if the first operand node is earlier than the second operand node in document order, or false
if the first operand node is later than the second operand node in document order.
A comparison with the >>
operator returns true
if the first operand node is later than the second operand node in document order, or false
if the first operand node is earlier than the second operand node in document order.
A comparison with the precedes
operator returns true
if the first operand node is reachable from the second operand node using the preceding axis; otherwise it returns false
.
A comparison with the follows
operator returns true
if the first operand node is reachable from the second operand node using the following axis; 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"]
A logical expression is either an and-expression or an or-expression. The value of a logical expression is always one of the boolean values true
or false
.
[6] | OrExpr | ::= | Expr "or" Expr |
[7] | AndExpr | ::= | Expr "and" Expr |
The first step in evaluating a logical expression is to reduce each of its operands to an effective boolean value by applying the following rules, in order:
If the operand is an empty sequence, its effective boolean value is false
.
If the operand is one simple boolean value, the operand serves as its own effective boolean value.
If the operand is a sequence that contains at least one node, its effective boolean value is true
.
In any other case, a type exception is invoked.
An and-expression returns the value true
if the effective boolean values of both of its operands are true
; otherwise it returns the value false
.
An or-expression returns the value false
if the effective boolean values of both of its operands are false
; otherwise it returns the value true
.
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 using the same rules that are used for the operands of logical expressions. 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
. The not
function is described in [XQuery 1.0 and XPath 2.0 Functions and Operators].
Ed. Note: Functions named
and3
,or3
, andnot3
may be provided to implement three-valued logic. See Issue 28.
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 element or attribute constructor can be used to create an element or attribute with a computed name.
[24] | Constructor | ::= | ElementConstructor | ComputedElementConstructor | ComputedAttributeConstructor |
[57] | ElementConstructor | ::= | "<" QName AttributeList ("/>" | (">" ElementContent* "</" QName ">")) |
[63] | ElementContent | ::= | Char
| "{{" | "}}" | ElementConstructor | EnclosedExpr | CdataSection | CharRef | PredefinedEntityRef | XmlComment | XmlProcessingInstruction | ComputedElementConstructor | ComputedAttributeConstructor |
[64] | AttributeList | ::= | (QName "=" (AttributeValue | EnclosedExpr))* |
[65] | AttributeValue | ::= | (["] AttributeValueContent* ["]) | (['] AttributeValueContent* [']) |
[66] | AttributeValueContent | ::= | Char
| CharRef | "{{" | "}}" | EnclosedExpr | PredefinedEntityRef |
[67] | EnclosedExpr | ::= | "{" ExprSequence "}" |
An element
constructor creates an XML element. If the name,
attributes, and content of the element are all constants, the
element constructor uses 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. If namespace prefixes are declared in the query prolog, the prefixes they declare may be used to create qualified names for elements and attributes. It is an error to use a namespace prefix that has not been declared.
Ed. Note: The type of an element created by an element constructor, and the validation or type assertions applied to such an element (if any), are currently open issues.
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:
<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 simple 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.
Ed. Note: The treatment of simple values and heterogeneous sequences when they occur in the content of a constructed element is an open issue. One approach would be to convert all simple values to CDATA during element construction. Another approach would be to preserve simple values in the data model, and allow an operator such as VALIDATE or CAST to create a normal XML-Schema representation of the data.
Whitespace in element constructors is always preserved, using the same behavior defined in XML 1.0 when xml:space is set to "preserve". Whitespace is also preserved in enclosed expressions.
An enclosed expression may also be used to compute the value of an attribute, as illustrated by the following two examples, which are equivalent:
<book isbn="{ $i/booknum }" />
<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, XQuery adopts the same convention as XSLT: Two adjacent curly braces in an XQuery character string are interpreted as a single curly brace character.
An alternative way to create elements and attributes is by
using a computed element constructor or a
computed attribute constructor. In these
constructors, the keyword element
or
attribute
is followed by the name of the node to
be created and then by its content. The name may be specified
either by a QName or by an enclosed expression that returns a QName, and the
content is specified by an enclosed expression.
[58] | ComputedElementConstructor | ::= | "element" (QName | EnclosedExpr) "{" ExprSequence? "}" |
[59] | ComputedAttributeConstructor | ::= | "attribute" (QName | EnclosedExpr) "{" 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" } } }
As the names imply, the primary 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
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:
element {$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>
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.
[60] | CdataSection | ::= | "<![CDATA[" Char* "]]>" |
[61] | XmlProcessingInstruction | ::= | "<?" PITarget Char* "?>" |
[62] | XmlComment | ::= | "<!--" Char* "-->" |
The following example illustrates constructors for processing instructions, comments, and CDATA sections.
<address><![CDATA[ <address>123 Roosevelt Ave. Flushing, NY 11368</address> ]]></address>
Ed. Note: It is not clear that the Data Model can represent a CDATA section.
Note that an XML comment actually constructs an XML comment node. An XQuery comment (see 2.2.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 -->
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.
[8] | FLWRExpr | ::= | (ForClause | LetClause)+ WhereClause? "return" Expr |
[27] | ForClause | ::= | "for" Variable "in" Expr ("," Variable "in" Expr)* |
[28] | LetClause | ::= | "let" Variable ":=" Expr ("," Variable ":=" Expr)* |
[29] | WhereClause | ::= | "where" Expr |
The clauses of a FLWR Expression are interpreted as follows:
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.
A let
clause binds a variable directly
to an entire 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.
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 the where-expression is computed by applying the following rules, in order:
If the where-expression returns an empty sequence, its effective boolean value is false
.
If the where-expression returns one simple boolean value, this value serves as the effective boolean value.
If the where-expression returns a sequence that contains at least one node, its effective boolean value is true
.
In any other case, a type exception is invoked.
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, the
variable is bound directly to the expression, and
it is bound to the expression as a whole. Consider the
following query:
let $s := (<one/>, <two/>, <three/>) return <out>{$s}</out>
The variable $s is bound to the expression (<one/>,
<two/>, <three/>)
. There are no for
clauses, so the let
clause generates one tuple that contains the
variable 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:
for $i in (1, 2), $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 unordered
function indicates that the order of a sequence is not significant and can be changed during processing of an expression. Using this function in the
expressions of a for
clause allows an implementation
more freedom in optimization, and the resulting
queries may be faster. The following query returns the
same results as above, but the tuples may occur in any order.
for $i in unordered(1, 2), $j in unordered(3, 4) return <tuple> <i>{ $i }</i> <j>{ $j }</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($in//author) return <author> { <name> { $a/text() } </name>, <books> { for $b in $input//book where $b/author = $a return $b/title } </books> } </author> } </authlist>
Here is the result of the above expression.
<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.
A sorting expression provides a way to control the order of items in a sequence.
[5] | SortExpr | ::= | Expr "stable"? "sortby" "(" SortSpecList ")" |
[26] | SortSpecList | ::= | Expr ("ascending" | "descending")? ("," SortSpecList)? |
The value of the expression on the left side of the sortby
keyword is called the input sequence. The items in the input sequence are called input items. The result of the sorting expression 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 sortby
keyword are called ordering expressions. For each input item, the ordering expressions are evaluated with that input item as the context item. 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).
The process of evaluating and comparing the ordering expressions is based on the following rules:
If the value of an ordering expression is a sequence containing more than one item, an error is raised.
If the value of an ordering expression is a node, its typed value is extracted. If the typed value is a sequence containing more than one simple value, an error is raised.
If the value of an ordering expression is an untyped simple value (such as character data in a schemaless document), it is treated as a string.
The values returned by an ordering expression for all input items must be comparable by the "gt
" operator--otherwise an error is raised.
For the purpose of the following rule, an implementation may consistently treat an empty sequence as greater than any non-empty value (that is, ( ) gt x
is true for any non-empty x
), or alternatively, it may consistently treat an empty sequence as smaller than any non-empty value (that is, x gt ( )
is true for any non-empty x
).
If V1 and V2 are the values of an ordering expression for input items I1 and I2 respectively, then:
If the ordering expression is ascending, and if V2 gt
V1 is true, then I1 precedes I2 in the output sequence.
If the ordering expression is descending, and if V1 gt
V2 is true, then I1 precedes I2 in the output sequence.
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.
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] sortby (author[1], title)
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> sortby(price descending) } </publisher> sortby(name) } </publisher_list>
Note:
Using a sortby
expression may cause unexpected results when combined with a path expression. Consider the following example:
(employees sortby (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 sortby (salary)) return $e/name
XQuery supports a conditional expression based on the keywords if
, then
, and else
.
[11] | IfExpr | ::= | "if" "(" Expr ")" "then" Expr "else" Expr |
The expression following the if
keyword is called the test expression, and the expressions following the then
and else
keywords are called result expressions.
The first step in processing a conditional expression is to find the effective boolean value of the test expression by applying the following rules, in order:
If the test expression returns an empty sequence, its effective boolean value is false
.
If the test expression returns one simple boolean value, this value serves as the effective boolean value.
If the test expression returns a sequence that contains at least one node, its effective boolean value is true
.
In any other case, a type exception is invoked.
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 first ("then") result expression is returned. If the effective boolean value of the test expression is false
, the value of the second ("else") result expression is returned.
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
Quantified expressions support existential and universal quantification. The value of a quantified expression is always true
or false
.
[9] | QuantifiedExpr | ::= | ("some" | "every") Variable "in" Expr "satisfies" Expr |
A quantified expression begins with a quantifier which is the keyword some
or every
. The quantifier is followed by a variable,
the keyword in
, a sequence
expression, the keyword
satisfies
,
and a test expression.
The sequence expression is evaluated, and for each value in the resulting sequence, the variable is bound to the given value and the test expression is evaluated.
The value of the quantified expression is defined by the following rules:
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 sequence expression returns an empty sequence, the value of the quantified expression is false
.
If the quantifier is every
, the quantified expression is
true
if every evaluation of the test expression has the effective boolean value
true
or returns a single node whose typed value is true
; otherwise the quantified expression is false
.
This rule implies that, if the sequence expression returns an empty sequence, the value of the quantified expression is true
.
The effective boolean value of the test expression is computed by applying the following rules, in order:
If the test expression returns an empty sequence, its effective boolean value is false
.
If the test expression returns one simple boolean value, this value serves as the effective boolean value.
If the test expression returns a sequence that contains at least one node, its effective boolean value is true
.
In any other case, a type exception is invoked.
Here are some examples of conditional 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)
It is sometimes necessary in XQuery to refer to a datatype. Datatypes are used in specifying the parameters of functions, and they are used explicitly in several kinds of XQuery expressions.
[53] | Datatype | ::= | (("element" "of" "type" QName) | DTKind | "node" | SimpleType | "item") OccurrenceIndicator |
[54] | DTKind | ::= | ("element" | "attribute") QName? |
[55] | SimpleType | ::= | QName |
[56] | OccurrenceIndicator | ::= | ("*" | "+" | "?")? |
An XML Schema simple type can be referred to by its
QName. For example, xs:string
refers to the XML
Schema simple type "string".
A global element or attribute defined in a Schema can be referred to by the keyword element
or attribute
followed by a QName. Such an element or attribute
must be defined exactly once in a Schema
available to the query. For example, element duck
refers to the globally defined duck
element in some schema that is available to the query.
One can also refer to all elements that have a given XML
Schema simple or complex type using the element of
type
keywords followed by
the QName of the type. For example, element of type
animal
refers to any element whose type is
animal
. Note that there might be several such
elements--for example, both duck
and
dog
elements might be of type
animal
.
The keyword element
without a QName indicates any element node. The keyword attribute
without a QName indicates any attribute node. The keyword node
indicates a node of any kind, including element, attribute, text, and other nodes as described in [XQuery 1.0 and XPath 2.0 Data Model]. The keyword item
indicates either a node or a simple value. These "wildcard" datatypes are useful in writing generic functions that operate on various kinds of values and in dealing with well-formed documents where type information is limited or unknown.
Any datatype can be followed by an occurrence indicator that indicates the allowed number of occurrences, using the following convention:
?
indicates zero or one occurrence of the given type
*
indicates zero or more occurrences of the given type
+
indicates one or more occurrences of the given type
Here are some examples of datatypes that might be used in XQuery expressions or function parameters:
xs:date
refers to the builtin Schema type date
attribute?
refers to an optional attribute
element office:letter
refers to an element with a specific name
element of type po:address+
refers to one or more elements 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 simple values
Datatypes occur explicitly in several kinds of XQuery expressions.
[16] | InstanceofExpr | ::= | Expr "instance" "of" "only"? Datatype |
[10] | TypeswitchExpr | ::= | "typeswitch" "(" Expr ")" ("as" Variable)? CaseClause+ "default" "return" Expr |
[30] | CaseClause | ::= | "case" Datatype "return" Expr |
[23] | CastExpr | ::= | ("cast" "as" | "treat" "as" | "assert" "as") Datatype "(" Expr ")" |
The Boolean operator instance of
returns true
if
its first operand is an instance of the type named
in its second operand; otherwise it returns false
. For example,
$x instance of element of type animal
returns true
if the value associated with variable $x
is an
element whose type is an instance of the type
animal
. If the keyword only
is
specified, instance of
returns true
only if the
result of the first operand exactly matches the specified type,
excluding subtypes from consideration. For example, $x instance of only element of type animal
returns
true
if $x
is an instance of animal
but not an instance of any subtype of animal
.
The typeswitch expression of XQuery allows users to perform different operations according to the type of an input expression.
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 operand expression can be followed by an
as
clause that defines a variable, called the
operand variable, that binds to the value of the operand
expression. The remainder of the typeswitch expression consists
of one or more case
clauses and a
default
clause.
Each case
clause specifies a datatype followed by a
return
expression. The effective case is the first
case
clause such that the value of the operand
expression is an instance of the datatype in the
case
clause. 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 an
instance 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.
The return
expressions in case
and
default
clauses typically contain references to the
operand variable (defined in the as
clause). If the
operand expression consists of a single variable, it can serve as
the operand variable and the as
clause can be omitted. The
as
clause can also be omitted if the
return
expressions do not contain references to the
operand variable.
The following example shows how a typeswitch expression might be used to invoke one of several functions depending on the type of a variable. This typeswitch expression might be used inside another function to simulate a primitive form of subtype polymorphism.
typeswitch ($animal) case element duck return quack($animal) case element dog return woof($animal) default return "No sound"
Occasionally it is necessary to explicitly convert a value from
one datatype to another. For the primitive and derived types of XML
Schema, a cast
expression is provided that can convert values between certain combinations of types. For example, the
expression cast as xs:integer (x div y)
converts the
result of x div y
into the xs:integer
type. The set of type conversions that are supported by the
cast
operator are specified in [XQuery 1.0 and XPath 2.0 Functions and Operators]. Conversions among user-defined datatypes are not
supported by the cast
notation, but user-defined
functions can be written for this purpose.
In addition to cast
, XQuery provides an expression called
treat
. Like cast
, treat
takes two operands: an expression and a datatype. The treat
expression checks whether the value of its expression operand
is an instance of its datatype operand. If it is, the treat
expression returns the value of the expression operand; otherwise, it returns an error.
The datatype operand must be a subtype of the expression operand's static type.
Unlike cast
, treat
does not change the value of its expression operand.
Treat
is typically used to guarantee that the dynamic type of a value
is a particular subtype of the value's static type. For example, assume
the static type of $myaddress
is Address
. The expression
treat as USAddress($myaddress)
checks during query evaluation
that the value of $myaddress
is an instance of the type USAddress
. This expression could then be used as an argument
to a function that requires a parameter of type USAddress
.
An assert
expression causes the XQuery processor to apply a check at query analysis time to ensure that the static type of the given expression is an instance of a given type. The assert
expression provides a stronger guarantee than a treat
expression because it is applied at query analysis time and is independent of input data, whereas treat
is applied during query execution and depends on the data that is being processed. The following example raises an error at query analysis time if the static type of the variable $myaddress
is not an instance of USAddress
:
assert as USAddress ($myaddress)
Ed. Note: The precise semantics of datatype operations depend on whether structural or named subtyping is used. The formal semantics document uses structural subtyping: one type is a subtype of another if every instance of the first is also an instance of the second. XML Schema uses named subtyping: one type is a subtype of another if the first is declared to be derived from the second. It is not immediately clear how to adopt the XML Schema approach to XQuery, because document validation works top-down while query evaluation is bottom-up. Whether the static and dynamic semantics of XQuery should be based on structural or named subtyping is still under discussion.
The Query Prolog is a series of declarations and definitions that affect query processing. The Query Prolog can be used to define namespaces, import definitions from schemas, and define functions.
[1] | Query | ::= | QueryProlog ExprSequence? |
[2] | QueryProlog | ::= | (NamespaceDecl
| DefaultNamespaceDecl | SchemaImport)* FunctionDefn* |
We describe the Query Prolog in two sections, one on Namespace Declarations and Schema Imports, and one on Function Definitions.
[68] | NamespaceDecl | ::= | "namespace" QName "=" StringLiteral |
[69] | DefaultNamespaceDecl | ::= | "default" ("element" | "function") "namespace" "=" StringLiteral |
[72] | SchemaImport | ::= | "schema" StringLiteral ("at" StringLiteral)? |
Ed. Note: The QName in NamespaceDecl should be a NCName. However, there is currently a technical problem with token ambiguity between QName and NCName.
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 an empty string. The namespace declaration is in scope for the rest of the query in which it is declared. Consider the following query:
namespace foo = "http://www.foo.com" <foo:bar> Lentils </foo:bar>
In the query result, the newly created node is in
the namespace associated with the namespace URI
http://www.foo.com
.
In element constructors, namespace declaration attributes also associate a namespace with a prefix, adding a (prefix, URI) pair to the set of in-scope namespaces. 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. Namespace declarations are in scope within their containing element. Nested elements and attributes inherit the in-scope namespaces of their parents. The following query creates the same result as the previous query.
<foo:bar xmlns:foo="http://www.foo.com"> Lentils </foo:bar>
Because namespace declarations are in-scope within their containing element, they may be used in expressions that occur within an element constructor, as in the following query.
<foo:bar xmlns:foo="http://www.foo.com">{ //foo:bing }</foo:bar>
Names are compared on the basis of the expanded name (see [XML Names] for this and other namespace terms), not the QName. When element or attribute names are compared, they are considered identical if the local part and namespace URI match. Namespace prefixes are disregarded in name comparisons. This is illustrated by the following example:
namespace xx = "http://www.foo.com" let $i := <foo:bar xmlns:foo = "http://www.foo.com"> <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://www.foo.com"
. 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>
It is invalid to redefine namespace prefixes using the NamespaceDecl production.
{-- Error: attempt to redefine 'xx' in NamespaceDecl --} namespace xx = "http://www.foo.com" namespace xx = "http://www.bar.com" //xx:bing
It is also invalid to use a QName with a namespace prefix that has not been declared. The following query is also semantically invalid.
{-- Error: use of undeclared namespace prefix --} //xx:bing
Namespace declaration attributes may redefine a namespace prefix within a given scope. The following query is valid.
namespace xx = "http://www.fee.com" <xx:bar xmlns:xx = "http://www.fie.com"> <xx:bing xmlns:xx = "http://www.fo.com"> One </xx:bing> <xx:bing xmlns:xx = "http://www.fum.com"> Two </xx:bing> <xx:bing> Three </xx:bing> </xx:bar>
The result of the above query is as follows.
<xx:bar xmlns:xx = "http://www.fie.com"> <xx:bing xmlns:xx = "http://www.fo.com"> One </xx:bing> <xx:bing xmlns:xx = "http://www.fum.com"> Two </xx:bing> <xx:bing xmlns:xx = "http://www.fie.com"> Three </xx:bing> </xx:bar>
Unless a default namespace is in effect, any element name, attribute name, or NameTest without a namespace prefix is not associated with a namespace. Hence, the following query returns the empty sequence.
namespace foo = "http://www.foo.com" let $i := <foo:bar> <bing>123</bing> </foo:bar> return $i/foo:bing
A Default Namespace Declaration defines a namespace URI that will be associated with any element name or element name test that does not have a namespace prefix, or with any function that does not have a namespace prefix. Different default namespaces can be specified for elements and for functions. Consider the following query:
default element namespace = "http://www.foo.com" <bar> Lentils </bar>
The following is the result of the above query. Note that the name of the newly created element is in the namespace associated with the namespace URI "http://www.foo.com", even though no namespace prefix occurs in the query.
<bar xmlns = "http://www.foo.com"> Lentils </bar>
As in XPath 1.0, the namespace URI of an attribute is null if the QName of the attribute does not have a prefix. In element constructors, unprefixed attributes create attribute nodes whose namespace URI is null. Attribute name tests without prefixes match attributes whose namespace URI is null.
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.
schema "http://www.w3.org/1999/xhtml at http:/www.w3.org/1999/xhtml/xhtml.xsd" namespace xhtml = "http://www.w3.org/1999/xhtml" document("aspect.xhtml")//xhtml:table
Ed. Note: Whether or not the locally declared elements and attributes of a schema are imported is an open issue.
It is an 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.
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.13 Datatypes. A function definition also includes an expression called the function body that defines how the result of the function is computed from its parameters.
[70] | FunctionDefn | ::= | "define" "function" QName "(" ParamList? ")" ("returns" Datatype)? EnclosedExpr |
[71] | ParamList | ::= | Param ("," Param)* |
[52] | Param | ::= | Datatype? Variable |
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, it accepts arguments of any type. If the returns
clause is omitted from a
function definition, the function may return a value of any type.
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"])
Each argument value to a function must be an instance of the argument's declared type, and the value of a function's body must be an instance of the function's return type. During static analysis, a query processor checks that that a value is an instance of its corresponding declared type by applying assert. At run-time, a query processor checks that the dynamic type of a value is an instance of its corresponding declared type by applying treat. This run-time application of treat may be omitted if the query has passed static analysis and is therefore known to be type correct.
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 a simple value as parameter (since a function call automatically extracts the simple 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 simple values from nodes when calling functions with simple value parameters.
Ed. Note: Rules for invoking functions on complex-type arguments are still an open issue, as noted under "Basic Conversion Rules." We need to discuss arguments that are a subtype of (or in the substitution group of) the expected parameter.
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 filtering a document to produce a table of contents, joins across multiple data sources, grouping and aggregates, and queries based on sequential relationships in documents.
One of the functions in the XQuery
core function library is called
filter
. This function
takes a single parameter which can be
any expression. The function evaluates
its argument and returns a shallow
copy of the nodes that are selected by
the argument, preserving any
relationships that exist among these
nodes. For example, suppose that the
argument to filter
is a
path expression that selects nodes X,
Y, and Z from some document. Suppose
that, in the original document, nodes
Y and Z are descendants (at any level)
of node X. Then the result of
filter
is a copy of node
X, with copies of nodes Y and Z as its
immediate children. Any other
intervening nodes from the original
document are not present in the
result. The name filter
suggests a function that operates on a
document to extract the parts that are
of interest and discard the remainder,
while retaining the structure of the
original document.
The semantics of
filter
are illustrated by
Figure 1. Suppose that the left side
of Figure 1 represents a node
hierarchy that is bound to the
variable $doc
. The right
side of Figure 1 shows the result of
the function filter($doc//(A |
B))
. The result contains copies
of all nodes of type A and B in the
original hierarchy, with their
original relationships preserved. Note
that the action of the
filter
function may split
a node hierarchy into multiple
hierarchies (preserving the sequential
relationships among the root nodes of
the resulting hierarchies.)
Figure 1: Action of the filter function |
The following example illustrates
how filter
might be used
to compute a table of contents for a
document that contains many levels of
nested sections. The query filters the
document, retaining only section
elements, title elements nested
directly inside section elements, and
the text of those title
elements. Other elements, such as
paragraphs and figure titles, are
eliminated, leaving only the
"skeleton" of the document. The example generates a table of contents for a document named cookbook.xml
.
<toc> { filter(document("cookbook.xml") // (section | section/title | section/title/text())) } </toc>
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:
A document named
parts.xml
that
contains many
part
elements;
each part
element in turn
contains
partno
and
description
subelements.
A document named
suppliers.xml
that
contains many
supplier
elements; each
supplier
element in turn
contains
suppno
and
suppname
subelements.
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> sortby(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 sortby(.) } </supplier> sortby(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> sortby (description) } </supplier> sortby (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 sortby (.) } </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.
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> sortby(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
.
XQuery uses the precedes
,
follows
, <<
,
and >>
operators to express
conditions based on sequence. Although these
operators are quite simple, they can be used
to express sophisticated queries for XML
documents in which sequence is meaningful.
The first two queries in this section involve
a surgical report that contains procedure
,
incision
, and anesthesia
elements. The
following query returns a critical sequence
that contains all elements and nodes found
between the first and second incisions of
the first procedure.
<critical-sequence> { let $proc := //procedure[1] for $n in $proc//node() where $n follows ($proc//incision)[1] and $n precedes ($proc//incision)[2] return $n } </critical-sequence>
The following query reports incisions for which no prior anesthesia was recorded in the surgical report.
for $p in //procedure where some $i in $proc//incision satisfies empty($proc//anesthesia[. precedes $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 := //h2[text()="Introduction"], $next-h := //(h1|h2)[. follows $intro][1] return <div> { $intro, if (empty($next-h)) then //node()[. follows $intro] else //node()[. follows $intro and . precedes $next-h] } </div>
Note that the above query also makes explicit the hierarchy that was implicit in the original document.
The following grammar uses the same Basic EBNF notation as [XML], except that grammar symbols always have initial capital letters. The EBNF contains only non-terminals, and all terminals are presented in a separate table.
Note:
Note that the Semicolon character is reserved for future use.
In the following table, operators with a higher precedence number are more tightly bound than operators with a lower precedence number. Operators listed at the same level are evaluated from left to right.
Precedence# | Productions |
---|---|
1 | SortExpr |
2 | OrExpr |
3 | AndExpr |
4 | FLWRExpr, QuantifiedExpr, TypeswitchExpr, IfExpr |
5 | GeneralComp, ValueComp, NodeComp, OrderComp |
6 | InstanceofExpr |
7 | RangeExpr |
8 | AdditiveExpr |
9 | MultiplicativeExpr |
10 | UnionExpr |
11 | IntersectExceptExpr |
12 | UnaryExpr |
13 | CastExpr, Constructor, PathExpr |
For readability, whitespace may be used in expressions even though not explicitly allowed by the grammar: Whitespace may be freely added within patterns before or after any token, except in a few cases where whitespace is needed to disambiguate the token:
A < symbol, when used as a less-than sign in comparisons, must always be followed by whitespace to distinguish it from the opening character in a tag. In tags, whitespace may not occur after the < symbol.
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, eg by using whitespace or parentheses.
A space may be significant after "/" or "//", in order to distinguish, for instance "//div" and "// div foo" without lookahead.
Tokens may be often only recognized in a specific state within the evaluation, and a token in turn may cause the grammar to transition to a different state. These state transitions are given below following the enumeration of tokens.
When tokenizing, the longest possible token is always returned. If there is an ambiguity between two tokens, the token that has an lower grammar number is more specific than a token with a higher grammar number.
All keywords and tokens are case sensitive.
ExprComment tokens should be ignored by the parser.
[75] | XmlCommentStart | ::= | "<!--" |
[76] | XmlCommentEnd | ::= | "-->" |
[77] | ExprComment | ::= | "{--" [^}]* "--}" |
[78] | S | ::= | WhitespaceChar+ |
[79] | ProcessingInstructionStart | ::= | "<?" |
[80] | ProcessingInstructionEnd | ::= | "?>" |
[81] | AxisChild | ::= | "child" "::" |
[82] | AxisDescendant | ::= | "descendant" "::" |
[83] | AxisParent | ::= | "parent" "::" |
[84] | AxisAttribute | ::= | "attribute" "::" |
[85] | AxisSelf | ::= | "self" "::" |
[86] | AxisDescendantOrSelf | ::= | "descendant-or-self" "::" |
[87] | DefineFunction | ::= | "define" "function" |
[88] | Or | ::= | "or" |
[89] | And | ::= | "and" |
[90] | AtKeyword | ::= | "at" |
[91] | Div | ::= | "div" |
[92] | Mod | ::= | "mod" |
[93] | Multiply | ::= | "*" |
[94] | In | ::= | "in" |
[95] | Satisfies | ::= | "satisfies" |
[96] | Return | ::= | "return" |
[97] | Then | ::= | "then" |
[98] | Else | ::= | "else" |
[99] | Default | ::= | "default" |
[100] | Namespace | ::= | "namespace" |
[101] | To | ::= | "to" |
[102] | Where | ::= | "where" |
[103] | Intersect | ::= | "intersect" |
[104] | Union | ::= | "union" |
[105] | Except | ::= | "except" |
[106] | Before | ::= | "before" |
[107] | After | ::= | "after" |
[108] | Precedes | ::= | "precedes" |
[109] | Follows | ::= | "follows" |
[110] | As | ::= | "as" |
[111] | Case | ::= | "case" |
[112] | Instanceof | ::= | "instance" "of" |
[113] | Only | ::= | "only" |
[114] | Returns | ::= | "returns" |
[115] | Function | ::= | "function" |
[116] | Element | ::= | "element" |
[117] | Item | ::= | "item" |
[118] | Attribute | ::= | "attribute" |
[119] | ElementOfType | ::= | "element" "of" "type" |
[120] | Node | ::= | "node" |
[121] | Ref | ::= | "ref" |
[122] | Schema | ::= | "schema" |
[123] | Nmstart | ::= | Letter | "_" |
[124] | Nmchar | ::= | Letter | CombiningChar | Extender | Digit | "." | "-" | "_" |
[125] | Star | ::= | "*" |
[126] | ColonStar | ::= | ":" "*" |
[127] | NCNameColonStar | ::= | ":"? NCName ":" "*" |
[128] | StarColonNCName | ::= | "*" ":" NCName |
[129] | Slash | ::= | "/" |
[130] | SlashSlash | ::= | "//" |
[131] | Equals | ::= | "=" |
[132] | EqualsEquals | ::= | "==" |
[133] | NotEquals | ::= | "!=" |
[134] | NotEqualsEquals | ::= | "!==" |
[135] | LtEquals | ::= | "<=" |
[136] | LtLt | ::= | "<<" |
[137] | GtEquals | ::= | ">=" |
[138] | GtGt | ::= | ">>" |
[139] | FortranEq | ::= | "eq" |
[140] | FortranNe | ::= | "ne" |
[141] | FortranGt | ::= | "gt" |
[142] | FortranGe | ::= | "ge" |
[143] | FortranLt | ::= | "lt" |
[144] | FortranLe | ::= | "le" |
[145] | ColonEquals | ::= | ":=" |
[146] | Lt | ::= | "<" S |
[147] | Gt | ::= | ">" |
[148] | Minus | ::= | "-" |
[149] | Plus | ::= | "+" |
[150] | QMark | ::= | "?" |
[151] | Arrow | ::= | "=>" |
[152] | Vbar | ::= | "|" |
[153] | Lpar | ::= | "(" |
[154] | At | ::= | "@" |
[155] | Lbrack | ::= | "[" |
[156] | Rpar | ::= | ")" |
[157] | Rbrack | ::= | "]" |
[158] | Variable | ::= | "$" QName |
[159] | Some | ::= | "some" |
[160] | Every | ::= | "every" |
[161] | For | ::= | "for" |
[162] | Let | ::= | "let" |
[163] | CastAs | ::= | "cast" "as" |
[164] | AssertAs | ::= | "assert" "as" |
[165] | TreatAs | ::= | "treat" "as" |
[166] | Digits | ::= | [0-9]+ |
[167] | IntegerLiteral | ::= | Digits |
[168] | DecimalLiteral | ::= | ("." Digits) | (Digits "." [0-9]*) |
[169] | DoubleLiteral | ::= | (("." Digits) | (Digits ("." [0-9]*)?)) ([e] | [E]) ([+] | [-])? Digits |
[170] | Comment | ::= | "comment" |
[171] | Text | ::= | "text" |
[172] | ProcessingInstruction | ::= | "processing-instruction" |
[173] | If | ::= | "if" |
[174] | Typeswitch | ::= | "typeswitch" |
[175] | Comma | ::= | "," |
[176] | SemiColon | ::= | |
[177] | Colon | ::= | ":" |
[178] | OpenQuot | ::= | ["] |
[179] | CloseQuot | ::= | ["] |
[180] | StringLiteral | ::= | (["] [^"]* ["]) | (['] [^']* [']) |
[181] | Dot | ::= | "." |
[182] | DotDot | ::= | ".." |
[183] | Sortby | ::= | "sortby" |
[184] | Stable | ::= | "stable" |
[185] | Ascending | ::= | "ascending" |
[186] | Descending | ::= | "descending" |
[187] | PITarget | ::= | NCName |
[188] | NCName | ::= | Nmstart Nmchar* |
[189] | QName | ::= | ":"? NCName (":" NCName)? |
[190] | CdataSectionStart | ::= | "<![CDATA[" |
[191] | CdataSectionEnd | ::= | "]]>" |
[192] | PredefinedEntityRef | ::= | "&" ("lt" | "gt" | "amp" | "quot" | "apos") ";" |
[193] | HexDigits | ::= | ([0-9] | [a-f] | [A-F])+ |
[194] | CharRef | ::= | "&#" (Digits | ("x" HexDigits)) ";" |
[195] | StartTagOpen | ::= | "<" |
[196] | StartTagClose | ::= | ">" |
[197] | EmptyTagClose | ::= | "/>" |
[198] | EndTagOpen | ::= | "</" |
[199] | EndTagClose | ::= | ">" |
[200] | ValueIndicator | ::= | "=" |
[201] | TagQName | ::= | QName |
[202] | Lbrace | ::= | "{" |
[203] | Rbrace | ::= | "}" |
[204] | LCurlyBraceEscape | ::= | "{{" |
[205] | RCurlyBraceEscape | ::= | "}}" |
[206] | OpenApos | ::= | ['] |
[207] | CloseApos | ::= | ['] |
[208] | Char | ::= | ([#x0009] | [#x000D] | [#x000A] | [#x0020-#xFFFD]) |
[209] | WhitespaceChar | ::= | ([#x0009] | [#x000D] | [#x000A] | [#x0020]) |
[210] | Whitespace | ::= | WhitespaceChar* |
[211] | Letter | ::= | BaseChar | Ideographic |
[212] | BaseChar | ::= | ([#x0041-#x005A] | [#x0061-#x007A] | [#x00C0-#x00D6] | [#x00D8-#x00F6] | [#x00F8-#x00FF] | [#x0100-#x0131] | [#x0134-#x013E] | [#x0141-#x0148] | [#x014A-#x017E] | [#x0180-#x01C3] | [#x01CD-#x01F0] | [#x01F4-#x01F5] | [#x01FA-#x0217] | [#x0250-#x02A8] | [#x02BB-#x02C1] | [#x0386] | [#x0388-#x038A] | [#x038C] | [#x038E-#x03A1] | [#x03A3-#x03CE] | [#x03D0-#x03D6] | [#x03DA] | [#x03DC] | [#x03DE] | [#x03E0] | [#x03E2-#x03F3] | [#x0401-#x040C] | [#x040E-#x044F] | [#x0451-#x045C] | [#x045E-#x0481] | [#x0490-#x04C4] | [#x04C7-#x04C8] | [#x04CB-#x04CC] | [#x04D0-#x04EB] | [#x04EE-#x04F5] | [#x04F8-#x04F9] | [#x0531-#x0556] | [#x0559] | [#x0561-#x0586] | [#x05D0-#x05EA] | [#x05F0-#x05F2] | [#x0621-#x063A] | [#x0641-#x064A] | [#x0671-#x06B7] | [#x06BA-#x06BE] | [#x06C0-#x06CE] | [#x06D0-#x06D3] | [#x06D5] | [#x06E5-#x06E6] | [#x0905-#x0939] | [#x093D] | [#x0958-#x0961] | [#x0985-#x098C] | [#x098F-#x0990] | [#x0993-#x09A8] | [#x09AA-#x09B0] | [#x09B2] | [#x09B6-#x09B9] | [#x09DC-#x09DD] | [#x09DF-#x09E1] | [#x09F0-#x09F1] | [#x0A05-#x0A0A] | [#x0A0F-#x0A10] | [#x0A13-#x0A28] | [#x0A2A-#x0A30] | [#x0A32-#x0A33] | [#x0A35-#x0A36] | [#x0A38-#x0A39] | [#x0A59-#x0A5C] | [#x0A5E] | [#x0A72-#x0A74] | [#x0A85-#x0A8B] | [#x0A8D] | [#x0A8F-#x0A91] | [#x0A93-#x0AA8] | [#x0AAA-#x0AB0] | [#x0AB2-#x0AB3] | [#x0AB5-#x0AB9] | [#x0ABD] | [#x0AE0] | [#x0B05-#x0B0C] | [#x0B0F-#x0B10] | [#x0B13-#x0B28] | [#x0B2A-#x0B30] | [#x0B32-#x0B33] | [#x0B36-#x0B39] | [#x0B3D] | [#x0B5C-#x0B5D] | [#x0B5F-#x0B61] | [#x0B85-#x0B8A] | [#x0B8E-#x0B90] | [#x0B92-#x0B95] | [#x0B99-#x0B9A] | [#x0B9C] | [#x0B9E-#x0B9F] | [#x0BA3-#x0BA4] | [#x0BA8-#x0BAA] | [#x0BAE-#x0BB5] | [#x0BB7-#x0BB9] | [#x0C05-#x0C0C] | [#x0C0E-#x0C10] | [#x0C12-#x0C28] | [#x0C2A-#x0C33] | [#x0C35-#x0C39] | [#x0C60-#x0C61] | [#x0C85-#x0C8C] | [#x0C8E-#x0C90] | [#x0C92-#x0CA8] | [#x0CAA-#x0CB3] | [#x0CB5-#x0CB9] | [#x0CDE] | [#x0CE0-#x0CE1] | [#x0D05-#x0D0C] | [#x0D0E-#x0D10] | [#x0D12-#x0D28] | [#x0D2A-#x0D39] | [#x0D60-#x0D61] | [#x0E01-#x0E2E] | [#x0E30] | [#x0E32-#x0E33] | [#x0E40-#x0E45] | [#x0E81-#x0E82] | [#x0E84] | [#x0E87-#x0E88] | [#x0E8A] | [#x0E8D] | [#x0E94-#x0E97] | [#x0E99-#x0E9F] | [#x0EA1-#x0EA3] | [#x0EA5] | [#x0EA7] | [#x0EAA-#x0EAB] | [#x0EAD-#x0EAE] | [#x0EB0] | [#x0EB2-#x0EB3] | [#x0EBD] | [#x0EC0-#x0EC4] | [#x0F40-#x0F47] | [#x0F49-#x0F69] | [#x10A0-#x10C5] | [#x10D0-#x10F6] | [#x1100] | [#x1102-#x1103] | [#x1105-#x1107] | [#x1109] | [#x110B-#x110C] | [#x110E-#x1112] | [#x113C] | [#x113E] | [#x1140] | [#x114C] | [#x114E] | [#x1150] | [#x1154-#x1155] | [#x1159] | [#x115F-#x1161] | [#x1163] | [#x1165] | [#x1167] | [#x1169] | [#x116D-#x116E] | [#x1172-#x1173] | [#x1175] | [#x119E] | [#x11A8] | [#x11AB] | [#x11AE-#x11AF] | [#x11B7-#x11B8] | [#x11BA] | [#x11BC-#x11C2] | [#x11EB] | [#x11F0] | [#x11F9] | [#x1E00-#x1E9B] | [#x1EA0-#x1EF9] | [#x1F00-#x1F15] | [#x1F18-#x1F1D] | [#x1F20-#x1F45] | [#x1F48-#x1F4D] | [#x1F50-#x1F57] | [#x1F59] | [#x1F5B] | [#x1F5D] | [#x1F5F-#x1F7D] | [#x1F80-#x1FB4] | [#x1FB6-#x1FBC] | [#x1FBE] | [#x1FC2-#x1FC4] | [#x1FC6-#x1FCC] | [#x1FD0-#x1FD3] | [#x1FD6-#x1FDB] | [#x1FE0-#x1FEC] | [#x1FF2-#x1FF4] | [#x1FF6-#x1FFC] | [#x2126] | [#x212A-#x212B] | [#x212E] | [#x2180-#x2182] | [#x3041-#x3094] | [#x30A1-#x30FA] | [#x3105-#x312C] | [#xAC00-#xD7A3]) |
[213] | Ideographic | ::= | ([#x4E00-#x9FA5] | [#x3007] | [#x3021-#x3029]) |
[214] | CombiningChar | ::= | ([#x0300-#x0345] | [#x0360-#x0361] | [#x0483-#x0486] | [#x0591-#x05A1] | [#x05A3-#x05B9] | [#x05BB-#x05BD] | [#x05BF] | [#x05C1-#x05C2] | [#x05C4] | [#x064B-#x0652] | [#x0670] | [#x06D6-#x06DC] | [#x06DD-#x06DF] | [#x06E0-#x06E4] | [#x06E7-#x06E8] | [#x06EA-#x06ED] | [#x0901-#x0903] | [#x093C] | [#x093E-#x094C] | [#x094D] | [#x0951-#x0954] | [#x0962-#x0963] | [#x0981-#x0983] | [#x09BC] | [#x09BE] | [#x09BF] | [#x09C0-#x09C4] | [#x09C7-#x09C8] | [#x09CB-#x09CD] | [#x09D7] | [#x09E2-#x09E3] | [#x0A02] | [#x0A3C] | [#x0A3E] | [#x0A3F] | [#x0A40-#x0A42] | [#x0A47-#x0A48] | [#x0A4B-#x0A4D] | [#x0A70-#x0A71] | [#x0A81-#x0A83] | [#x0ABC] | [#x0ABE-#x0AC5] | [#x0AC7-#x0AC9] | [#x0ACB-#x0ACD] | [#x0B01-#x0B03] | [#x0B3C] | [#x0B3E-#x0B43] | [#x0B47-#x0B48] | [#x0B4B-#x0B4D] | [#x0B56-#x0B57] | [#x0B82-#x0B83] | [#x0BBE-#x0BC2] | [#x0BC6-#x0BC8] | [#x0BCA-#x0BCD] | [#x0BD7] | [#x0C01-#x0C03] | [#x0C3E-#x0C44] | [#x0C46-#x0C48] | [#x0C4A-#x0C4D] | [#x0C55-#x0C56] | [#x0C82-#x0C83] | [#x0CBE-#x0CC4] | [#x0CC6-#x0CC8] | [#x0CCA-#x0CCD] | [#x0CD5-#x0CD6] | [#x0D02-#x0D03] | [#x0D3E-#x0D43] | [#x0D46-#x0D48] | [#x0D4A-#x0D4D] | [#x0D57] | [#x0E31] | [#x0E34-#x0E3A] | [#x0E47-#x0E4E] | [#x0EB1] | [#x0EB4-#x0EB9] | [#x0EBB-#x0EBC] | [#x0EC8-#x0ECD] | [#x0F18-#x0F19] | [#x0F35] | [#x0F37] | [#x0F39] | [#x0F3E] | [#x0F3F] | [#x0F71-#x0F84] | [#x0F86-#x0F8B] | [#x0F90-#x0F95] | [#x0F97] | [#x0F99-#x0FAD] | [#x0FB1-#x0FB7] | [#x0FB9] | [#x20D0-#x20DC] | [#x20E1] | [#x302A-#x302F] | [#x3099] | [#x309A]) |
[215] | Digit | ::= | ([#x0030-#x0039] | [#x0660-#x0669] | [#x06F0-#x06F9] | [#x0966-#x096F] | [#x09E6-#x09EF] | [#x0A66-#x0A6F] | [#x0AE6-#x0AEF] | [#x0B66-#x0B6F] | [#x0BE7-#x0BEF] | [#x0C66-#x0C6F] | [#x0CE6-#x0CEF] | [#x0D66-#x0D6F] | [#x0E50-#x0E59] | [#x0ED0-#x0ED9] | [#x0F20-#x0F29]) |
[216] | Extender | ::= | ([#x00B7] | [#x02D0] | [#x02D1] | [#x0387] | [#x0640] | [#x0E46] | [#x0EC6] | [#x3005] | [#x3031-#x3035] | [#x309D-#x309E] | [#x30FC-#x30FE]) |
XQuery has lexical states that distinguish literal XML from XQuery expressions. In literal XML, any name may be used as an element name or attribute name, even if it is a reserved word in XQuery's expression syntax. To make this possible, XQuery uses separate lexical states for start tags and end tags. Similarly, strings that would be treated as a reserved keyword in XQuery's expression syntax are treated as normal character sequences when they occur in element content, attribute values, processing instructions, XML comments, or CDATA sections. The following example contains the string "FOR" many times, but this string is always interpreted the same way that it would be by a native XML parser, not as an XQuery keyword:
<for for="for"> for <!-- for --> <?for for="for"?> <![CDATA[ for ]]> </for>
An XQuery tokenizer begins in the DEFAULT state, which recognizes XQuery expressions rather than literal XML. In the DEFAULT state, the "<" character, when not followed by whitespace, marks a transition to native XML syntax. When followed by whitespace, it is treated as the less-than sign, and there is no state transition.
Before changing state, the tokenizer pushes the current state to a stack. In the DEFAULT state, the strings"<!--", "<?", and "<![CDATA[" are recognized as tokens which are associated with transitions to the XML_COMMENT, PROCESSING_INSTRUCTION, and CDATA_SECTION states, respectively. In these states, the strings "-->", "?>", and "]]>" are recognized as tokens that mark the end of the relevant XML construct, at which point the tokenizer pops the state.
Element constructors also push the current state, popping it at the conclusion of an end tag. However, several lexical transitions occur between the beginning and end of an element constructor. The character "<", unless followed by whitespace, "!--", "?", or "![CDATA[", is treated as the beginning of a start tag, which is associated with a transition to the START_TAG state. This state allows attributes in the native XML syntax. In the START_TAG state, the string ">" is recognized as a token which is associated with the transition to the ELEMENT_CONTENT state. In the ELEMENT_CONTENT state, the string "</" is interpreted as the beginning of an end tag, which is associated with a transition to 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.
In element content or attribute values, ie in the ELEMENT_CONTENT, QUOT_ATTRIBUTE_CONTENT, or APOS_ATTRIBUTE_CONTENT states, the character "{" marks a transition to the DEFAULT state. Before making this transition, the current state is pushed so that it can be popped when the corresponding "}" is encountered. 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.
Any lexical pattern that is not recognized under a given state will be an unrecognized token, and thus an error.
An operator that immediately follows a "/" or "//" when used as a root symbol, should not parse. For example, the following expression, which the expression writer may intend to parse as (/) * foo
(value of the root element multiplied by the value of the foo element) would parse as (/*) foo
, and thus would be an error:
/ * foo
This must instead be written as:
(/) * foo
tokens | recognize state | next state | action |
---|---|---|---|
WhitespaceChar Nmstart NCName Nmchar Digits Letter BaseChar Ideographic CombiningChar Digit Extender HexDigits Whitespace S | |||
XmlCommentStart | DEFAULT ELEMENT_CONTENT | XML_COMMENT | pushState |
XmlCommentEnd | XML_COMMENT | popState | |
ExprComment | DEFAULT ELEMENT_CONTENT | ||
ProcessingInstructionStart | DEFAULT ELEMENT_CONTENT | PROCESSING_INSTRUCTION | pushState |
ProcessingInstructionEnd | PROCESSING_INSTRUCTION | popState | |
PITarget | PROCESSING_INSTRUCTION | ||
CdataSectionStart | ELEMENT_CONTENT | CDATA_SECTION | |
CdataSectionEnd | ELEMENT_CONTENT CDATA_SECTION | ELEMENT_CONTENT | |
PredefinedEntityRef CharRef | ELEMENT_CONTENT QUOT_ATTRIBUTE_CONTENT APOS_ATTRIBUTE_CONTENT | ||
StartTagOpen | DEFAULT ELEMENT_CONTENT QUOT_ATTRIBUTE_CONTENT APOS_ATTRIBUTE_CONTENT | START_TAG | pushState |
StartTagClose | START_TAG | ELEMENT_CONTENT | |
EmptyTagClose | START_TAG | popState | |
EndTagOpen | ELEMENT_CONTENT | END_TAG | |
EndTagClose | END_TAG | popState | |
TagQName | START_TAG END_TAG | ||
ValueIndicator | START_TAG | ||
Lbrace | START_TAG END_TAG ELEMENT_CONTENT QUOT_ATTRIBUTE_CONTENT APOS_ATTRIBUTE_CONTENT DEFAULT | DEFAULT | pushState |
LCurlyBraceEscape RCurlyBraceEscape | ELEMENT_CONTENT QUOT_ATTRIBUTE_CONTENT APOS_ATTRIBUTE_CONTENT | ||
Rbrace | DEFAULT | popState | |
OpenQuot | START_TAG | QUOT_ATTRIBUTE_CONTENT | |
CloseQuot | QUOT_ATTRIBUTE_CONTENT | START_TAG | |
OpenApos | START_TAG | APOS_ATTRIBUTE_CONTENT | |
CloseApos | APOS_ATTRIBUTE_CONTENT | START_TAG | |
Char | ELEMENT_CONTENT CDATA_SECTION QUOT_ATTRIBUTE_CONTENT APOS_ATTRIBUTE_CONTENT PROCESSING_INSTRUCTION XML_COMMENT XQUERY_COMMENT |
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).
Num | Cl | Cluster | Status | Locus | Description | Originator |
---|---|---|---|---|---|---|
134 | (de)reference-expr | draft | xquery | Dereference Operator and Links | Jonathan Robie | |
92 | (in)equality-operators | active | xpath | Deep equality | Jonathan | |
95 | (in)equality-operators | active | xpath | Equality will not be compatible with some string conversions | mhkay@iclway.co.uk | |
96 | (in)equality-operators | active | xpath | Normalized Equality | Mary Fernandez | |
91 | (in)equality-operators | draft | xpath | 9. String comparisons: | XQuery | |
26 | 3-value-logic | active | xpath | Should we default then to return an empty sequence? | marsh@microsoft.com | |
28 | 3-value-logic | active | xpath | Do we need and3(), or3(), not3() built in? | XSL WG | |
175 | 3-value-logic | active | xpath | What should "not3()" be called? | XQuery WG | |
215 | 3-value-logic | active | xpath | Should we have a 3-valued form of quantifiers? | Andrew Eisenberg | |
30 | 3-value-logic | draft | xfo | Should comparison operations always return null if either of the arguments are null? | Editor | |
67 | ASSERT-expr | draft | xquery | Static Type Assertions | Mary | |
132 | attribute accessors | draft | xfo | Attribute Name, Attribute Content | Don Chamberlin | |
113 | axes | draft | xpath | What should the mechanism be for axis subsetting? | jmarsh@microsoft.com | |
114 | axes | draft | xquery | XPath Axes | XQuery Editors | |
176 | choice-context | active | xpath | What is a node sequence? | XPath-TF | |
177 | choice-context | active | xpath | Consistency of functions that take boolean formal argument | XPath-TF | |
15 | choice-context | draft | xpath | Implicit conversion of node-sets to boolean for comparisons. | XQuery, jmarsh@microsoft.com | |
169 | conformance | unassigned | xquery | Missing conformance section | Jonathan | |
238 | consistency | active | xpath | Consistency: tradeoff between interoperability and efficiency | Phil Wadler | |
239 | consistency | active | xpath | Consistency: bracketing of nested expressions | Phil Wadler | |
240 | consistency | active | xpath | Consistency: parenthesizing test expressions | Phil Wadler | |
241 | consistency | active | xpath | Consistency: keywords | Phil Wadler | |
147 | constructor-expr | decided | xquery | Empty Attributes | XQuery | |
148 | constructor-expr | draft | xpath | Namespace Attributes in Element Constructors | XML Query | |
145 | constructor-expr | unassigned | xquery | Copy and Reference Semantics | XQuery Editors | |
146 | constructor-expr | unassigned | xquery | Jonathan | ||
135 | constructor-syntax | active | algebra | Empty End Tags in Element Constructors | Michael Rys | |
136 | constructor-syntax | active | xquery | Lists of Element Constructors | Michael Rys | |
137 | constructor-syntax | draft | xquery | Attribute Constructor Function | Don Chamberlin | |
138 | constructor-syntax | draft | xquery | Quotes for computed attribute values | James Clark | |
139 | constructor-syntax | draft | xquery | Computed element and attribute names | XQuery Editors | |
141 | constructor-syntax | draft | xquery | Productions for Comments and Processing Instructions | Don Chamberlin | |
143 | constructor-syntax | unassigned | algebra | XML Constructor | Jonathan Robie | |
69 | context | active | xquery | Mapping Input Context | Jerome Simeon | |
230 | context | active | xpath | Context document adequate for multiple docuemnts? | Michael Rys | |
68 | context | decided | xpath | Do we need a Context Item, and, if so, how should it work? | Editor | |
70 | context | decided | xpath | Does the context include a default namespace declaration? | mhkay@iclway.co.uk | |
71 | context | decided | xpath | Do we need a datatype names binding in the context? | Editor | |
72 | context | decided | xpath | How should qname-to-collation bindings be handled? | Editor | |
100 | datamodel | draft | datamodel | Should an empty sequence and an empty node-set be distinguishable? | Editor | |
170 | documents | unassigned | xquery | Document collections | XQuery WG | |
125 | editorial | active | xpath | Should we say something about the abstractness of XPath? | Editor | |
126 | editorial | active | xpath | Should we re-explain path expressions? | mhkay@iclway.co.uk | |
97 | error | active | xpath | How should the error object be supported? | Editor | |
98 | error | active | xpath | General discussion of errors | XML Query WG | |
99 | error | unassigned | xquery | TRY/CATCH and error() | XQuery Editors | |
160 | execution-model | active | xquery | Naive Implementation Strategy | Marton Nagy | |
226 | existential expressions | active | xpath | Existential Expressions | Mike Kay | |
231 | fallback | active | xpath | data(SimpleValue) is error or no-op? | XSL WG | |
163 | filter | unassigned | algebra | Typing of Filter | Jerome Simeon | |
216 | focus | active | xpath | Description of focus is very procedural | Michael Rys | |
217 | focus | active | xpath | Context document in focus | Michael Rys | |
32 | for-expr | decided | xpath | Do we really require for at the XPath expression level? | K Karun | |
105 | function-app | active | xpath | Implicit current node for functions? | XQuery Editors | |
108 | function-app | active | xpath | Aggregate functions on empty sequences. | XQuery | |
102 | function-app | decided | xpath | Functions on Empty Sequences | XQuery | |
103 | function-app | decided | xpath | Functions on Sequences | XQuery | |
107 | function-app | decided | xpath | Path iteration | XQuery | |
180 | functions | active | xpath | Functions expecting complex-valued arguments | XPath-TF | |
158 | functions | draft | xquery | Unqualified Function Names | XML Query | |
124 | functions | unassigned | xquery | External Functions | XQuery Editors | |
157 | functions | unassigned | xquery | Function Libraries | XQuery Editors | |
223 | functions external | active | xquery | We need a way to declare external functions | Michael Rys | |
3 | grammar | active | xpath | What should be the precedence of a RangeExpr be? | Editor | |
168 | groupby | unassigned | xquery | GROUPBY | XML Query | |
59 | INSTANCEOF-expr | active | xpath | We need precise semantics for instanceof. | mhkay@iclway.co.uk | |
151 | literal-XML | unassigned | xquery | Cutting and pasting XML into XQuery | XQuery Editors | |
166 | miscellaneous | unassigned | xquery | Excluding Undesired Elements | Don Chamberlin | |
74 | module-semantics | active | xquery | Module syntax | XQuery Editors | |
77 | module-semantics | draft | xquery | Namespace Prefix Redefine | XML Query | |
75 | module-semantics | unassigned | xquery | Importing Modules | XQuery Editors | |
79 | module-syntax | unassigned | xquery | Encoding | Jonathan Robie | |
228 | namespace functions | active | xpath | Should we keep the default function namespace, and the xf: namespace? | Scott Boag | |
201 | namespaces | active | xquery | Scope of namespace declaration | XPath Editors | |
202 | namespaces | active | xquery | In-scope namespaces and bindings | XPath Editors | |
203 | namespaces | active | xquery | Non declared namespace prefix | XPath Editors | |
204 | namespaces | active | xquery | How do default element namespaces affect attributes | XPath Editors | |
219 | namespaces | active | xquery | Context: namespaces | Michael Rys | |
221 | namespaces | active | xquery | Where should namespace prefixes apply? | Michael Rys | |
222 | namespaces | active | xquery | Allow redefinition of namespace prefixes? | Michael Rys | |
85 | node-equality | draft | xfo | Identity-based equality operator | Algebra Editors | |
86 | node-equality | draft | xpath | Set operations based on value | XQuery Editors | |
186 | node order | active | xpath | Ordering of result of union, intersect, and except operators | XPath Editors | |
184 | node-types | active | xpath | Need ability to test for Comments, PIs | F&O TF | |
19 | nulls-empty | active | xpath | How should null be treated in the data model? | XSL WG | |
182 | operator | active | xpath | Mapping XPath Operators to F&O Functions | XPath TF | |
187 | operators | active | xpath | Operations supported on date/time types | XPath Editors | |
188 | operators | active | xpath | Comparison operators - concrete syntax | XPath Editors | |
189 | operators | active | xpath | Supported combinations of types for comparison operators | XPath Editors | |
190 | operators | active | xpath | Operators for order comparisons | XPath Editors | |
210 | order sequences | active | xpath | Order of sequences | Phil Wadler | |
234 | order sequences | active | xpath | Who defines sorting order of ()? | Phil Wadler | |
119 | path-semantics | active | xpath | Should nonsense nodetests be disallowed? | jmarsh@microsoft.com | |
115 | path-semantics | draft | xpath | General Expressions in Path Steps | ||
117 | path-semantics | draft | xpath | Disallow variables on right side of slash? | Editor | |
118 | path-semantics | draft | xpath | Disallow obvious non-node sequences on left of slash? | Editor | |
5 | reserved-words | active | xpath | Reserved words | XQuery | |
8 | reserved-words | decided | xpath | Case-Sensitivity in Keywords | XML Query | |
123 | serialization | active | xquery | Linearization/Serialization | XQuery | |
36 | SOME-expr | active | xpath | Quantifiers with multiple bindings? | Don Chamberlin | |
194 | sort | active | xquery | Support for stable and unstable sort? | XPath Editors | |
195 | sort | active | xquery | Semantics of sorting heterogeneous sequences | XPath Editors | |
220 | sort | active | xpath | Should there be a way to explicitly sort in document order? | Michael Rys | |
154 | SORT-expr | draft | xquery | Ordering of empty values. | XQuery | |
155 | SORT-expr | unassigned | xquery | Sorting by Non-exposed Data | Michael Rys | |
109 | syntax | active | xpath | Need text to disambiguate Lexical Structure? | mhkay@iclway.co.uk | |
212 | syntax | active | xpath | Is "datatype" a suitable production name? | Phil Wadler | |
229 | syntax | active | xpath | Do we need both << and precedes? | XQuery/XSL WGs | |
233 | syntax | active | xquery | Simpler FLWR syntax? | Phil Wadler | |
235 | syntax | active | xpath | Need parenthesis in conditional expression? | Phil Wadler | |
236 | syntax | active | xpath | SimpleType preceded by a keyword? | Phil Wadler | |
237 | syntax | active | xpath | Need parenthesis in type switch expression? | Phil Wadler | |
144 | syntax | draft | xquery | Escaping Quotes and Apostrophes | XML Query | |
112 | syntax | unassigned | xquery | Leading Minus | XML Query | |
209 | syntax attribute values | active | xpath | Syntax for attribute values - more than one? | Phil Wadler | |
208 | syntax curly brace | active | xquery | Multiple curly braces allowed? | Phil Wadler | |
227 | syntax dereference | active | xpath | Syntax for dereference? | Don Chambrelin | |
232 | syntax operators date | active | xpath | Use "+" and "-" on dates and durations? | Phil Wadler | |
213 | syntax quotes | active | xpath | How to get quotes etc in string literals? | Andrew Eisenberg | |
214 | syntax strings in attributes | active | xpath | Strings in attributes | Andrew Eisenberg | |
183 | text-nodes | active | xpath | Text nodes - lexical structure and typed form | XPath TF | |
192 | type constructed element | active | xquery | Type of a newly constructed element | XPath Editors | |
81 | typed-value/data() | active | datamodel | What should the typed value of a complex type be? | jmarsh@microsoft.com | |
172 | typed-value/data() | active | xpath | Some functions taking node sequences and implicitly map? | XPath TF | |
80 | typed-value/data() | decided | xpath | Accessing Element Data | Mary Fernandez | |
54 | type-errors | active | xquery | Queries with Invalid Content | XQuery Editors | |
55 | type-errors | draft | xquery | Static versus Dynamic Errors | Algebra | |
174 | type exception | active | xpath | Support for UnknownSimpleType | XPath TF f2f | |
185 | type exception | active | xpath | Always explicit cast? | Phil Wadler | |
173 | type exception | draft | xpath | Polymorphic operator; only one fallback? | XPath TF f2f | |
196 | types | active | xpath | Concrete syntax for datatype declarations | XPath Editors | |
197 | types | active | xpath | Need "attribute of type"? | XPath Editors | |
198 | types | active | xpath | Syntax for named typing | XPath Editors | |
199 | types | active | xpath | Support for locally declared types? | XPath Editors | |
200 | types | active | xpath | Semantics of "only" | XPath Editors | |
205 | types | active | xquery | Default function parameter type | XPath Editors | |
206 | types | active | xpath | Typing support in XPath | Mike Kay | |
211 | types | active | xpath | Treat and structural vs named typing | Phil Wadler | |
224 | types | active | xquery | Why do we want to allow optional returns and DataType? | Michael Rys | |
40 | type-semantics | active | xquery | Correspondence of Types | Jerome Simeon | |
41 | type-semantics | active | xquery | Static type-checking vs. Schema validation | Mary Fernandez | |
42 | type-semantics | active | xquery | Implementation of and conformance levels for static type checking | Don | |
43 | type-semantics | active | xquery | Defining Behavior for Well Formed, DTD, and Schema Documents | Don Chamberlin | |
44 | type-semantics | active | xquery | Support for schema-less and incompletely validated documents | Don Chamberlin/Mary Fernandez | |
45 | type-semantics | active | xquery | Names in Type Definitions | Don | |
46 | type-semantics | active | xquery | typeof() function | Jonathan | |
47 | type-semantics | active | xquery | Subtype Substitutability | XQuery Editors | |
48 | type-semantics | active | algebra | CASE not a subtype | XML Query | |
49 | type-semantics | draft | xquery | Substitution Groups | XQuery Editors | |
50 | type-semantics | draft | xquery | Function Definition | XQuery Editors | |
51 | type-semantics | draft | xquery | Function Resolution | XQuery Editors | |
56 | type-syntax | active | xquery | Human-Readable Syntax for Types | Algebra Editors | |
57 | type-syntax | active | xquery | Inline XML Schema Declarations | Don Chamberlin | |
58 | type-syntax | draft | xquery | Importing Schemas and DTDs into query | Don Chamberlin | |
181 | type-system | active | xpath | Should literals include integers & integer be treated as primitive type? | Michael Kay | |
164 | updates | unassigned | xquery | Updates | XQuery Editors | |
207 | variables | active | xpath | Variable names: QNames or NCnames? | Ashok Malhotra | |
225 | variables | active | xpath | Variable redefinition allowed? | Mike Kay | |
191 | whitespace | active | xquery | Whitespace handling in element constructors | XPath Editors | |
218 | wildcards | active | xpath | What wildcards; namespaceprefix? | Michael Rys | |
193 | xml non representable | active | xquery | Construction of non representable XML | XPath Editors | |
130 | xquery-alignment | active | algebra | Algebra Mapping | XQuery Editors | |
152 | xqueryx | active | xqueryx | XML-based Syntax | XML Query WG | |
153 | xqueryx | active | xquery | Escape between syntaxes | Jerome Simeon |
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.
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] .
Should keywords in XQuery be case-sensitive?
Decision by: xsl on 2001-12-07 ([link to member only information] )(joint meeting)
Decision by: xquery on 2001-12-07 ([link to member only information] )(joint meeting)
Keywords are case-sensitive and it was also decided to use only lower-case keywords in the current XQuery / XPath WD. Thtopchange the text, the grammar, and the examples.
In XPath 1.0, a node-set can be used in a Boolean context, and it is considered to have the value True if it is non-empty. But XQuery believes that a node-set containing one element with value False should not be implicitly converted to True. For example, if married is a Boolean-valued subelement of person, XQuery does not believe that //person[married="True"] should return persons whose married subelement has value False.
The section on comparisons performs exceptional treatment for node-set to Boolean conversions. Jonathan Marsh does not support such an exception. Either we should remove the exception and take the backward compatibility hit, or we should define a different mechanism to access the typed-value so that the compatibility question is avoided.
[link to member only information] Michael Rys:
The following proposal tries to provide a solution to the following issues: XPath2-Issue-14 (node-set-conversion): Implicit conversion of node-sets to boolean for comparisons. Priority: 1 Originator: XQuery, jmarsh@microsoft.com Locus: Syntax XQuery-XPath2-Issue-2 Converting node-sets to Boolean. XQuery-Issue-64 Converting general expressions to boolean and is related to the following issues: F&O Issue 85 : The semantics of xf:boolean(node) is underspecified (operator-boolean-node-unspecified) We would appreciate if this could be scheduled quickly and accepted. Assumptions ----------- I use the function typed-value(node) from the data model as a synonym for the actual language accessor /data(). Problem description ------------------- XPath 1.0 defines an implicit conversion of node-sets N to boolean in a way that any such conversion is defined as not(empty(N)). This is a useful definition for being able to define node tests of the forms (A) a[@b] (B) a[b or b/c = 4] but unfortunately conflicts with the general rules of typed-value access as requested by XQuery for expressions such as (C) a[@b=$val] In such expressions, if $val is bound to an integer value expression then the expected rules are: let $val := 5 return a[@b=$val] becomes (after expression rewrite and implicit typed-value access): a[typed-value(@b) = 5] If $val binds to a boolean value, the same expression unfortunately is in contradiction with the XPath 1.0 semantics: let $val := xf:false() return a[@b=$val] becomes (after expression rewrite and implicit typed-value access): a[typed-value(@b) = xf:false()] XPath 1.0 semantics would be: a[not(empty(@b)) = xf:false()] Summary of the proposal ----------------------- The following proposal tries to preserve the XPath 1.0 semantics for cases (A) and (B) while preserving the typed-value access for case (C). Impact: It will preserve XPath 1.0 backwards-compatibility for the 80% use case but break it in the 20% use case. Details ------- 1. Generally, if a node or node sequence is passed as a parameter to a function or operator where a boolean value is expected, an attempt is made to extract the typed-value of the node(s) subject to the conversion rules of the nodes type to boolean. Comment: This will cover (C) to be always a[typed-value(@b) = $val] regardless of the type of $val. 2. The following exceptions hold: 2 (a) If the operation is a predicate (either the [] shortform or the where clause in FLWR), then a node or node sequence will be translated into a node test instead of accessing the typed value. 2 (b) If the operation is the not() function or the and or or operators, an argument expression that results in a node or node sequence will be translated into a node test instead of accessing the typed value. Comment: This will preserve the useful XPath 1.0 compability for cases (A) and (B). Note that we have special cased these operations already, so the special casing is less of a problem than it may seem. Open Issues ----------- The XPath 1.0 semantics uses xf:boolean(node) to define the node test semantics. XQuery's cast currently does not clarify if it performs implicit typed-value access on CAST as xsd:boolean (node) or if it is an error (to allow casting to user defined complex types in the future). In either case it does not perform a node test. The question is whether xf:boolean in XPath 2.0 should be the node test or CAST as xsd:boolean(typed-value(node)). I prefer the later, but am open to strong pushback.
Cf. Consistency of functions that take boolean formal argument
Decision by: xpath-tf on 2001-11-06 ([link to member only information] )
Agreed that choice context is not necessary for XPath predicates. Standard fallback conversions will handle case when required value is optional boolean but actual value is not.
Decision by: xpath-tf on 2001-11-13 ([link to member only information] )
Adoption of Michael R's proposal in [link to member only information: Proposal to close issue expr[nodes]] .
Decision by: xpath-tf on 2001-11-20 ([link to member only information] )
There have been some problems called to attention on the editor's list about the decision made at the telcon concerning dealing with nodes in predicates and the like.
The issue will be discussed at the F2F meeting.
Text is in Working Draft 2001-11-28 sec 2.3.
Text is in Working Draft 2001-11-28 sec 2.7.
Text is in Working Draft 2001-11-28 sec 2.11.
Text is in Working Draft 2001-11-28 sec 2.12.
Sequences are defined to not be able to contain sequences. Yet, it is probably that we need to be able to represent null in sequences in order to maintain cardinality for table processing and the like.
Proposal: Nulls are a special value or an empty sequence: It is a special value when it is a member of a sequence. It is an empty sequence for type checking and iteration. This may require tagging empty sequences that were returned as null with a flag. The XSL WG has not reached resolution on this proposal.
Conflicts with : [link to subsumed issue: null-missing-data] .
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.
For functions, the null (empty sequence) is passed to the function, the precedent set by SQL. Should comparison operations act the same, or should they be defined to always return an empty sequence in this case?
Text is in Working Draft 2001-11-28 sec 2.6.
for
at the XPath
expression level?
Is for
really a proper construct for a simple
expression language? Will the definition of for
in
XPath cause problems for XQuery?
[link to member only information] Michael Kay:
Decision by: xpath-tf on 2001-11-27 ([link to member only information] )
Decision by: xsl on 2001-11-29 ([link to member only information] )
Adoption of FOR expression in XPath 2.0.
Scott Boag will provide 'tips & traps' text on potential semantic problems of mixing FOR, '/' and SORT.
Text is in Working Draft 2001-11-28 sec 2.9, paragraph 2.
We have considered forms of quantified expressions that bind several variables at once, as in SOME $x IN expr1, $y IN expr2. Are such quantifiers desireable? If so, what are their semantics, and what use cases support them? Note that there is no additional expressive power over the current single-variable syntax, this is purely a question of convenience.
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 (see <link href="Algebra"></link>. 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.
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] .
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] .
This is related to #xquery-schema-importxquery-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] .
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.
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.
How should XQuery handle XML Schema substitution groups with respect to name tests in paths? With respect to parameter types and return types in functions?
Text is in Working Draft 2001-11-28 sec 2.13.
We need more thought about what constitutes a valid parameter-type for a function. Attribute-types as well as element-types? Type-names vs. element-names? Should all the MSL symbol spaces be represented? Wildcards? Sequences?
It is probably important to have NODE as a type, to allow functions to take any XML node as a parameter, or to return any XML node as a result.
Using univeral names similar to those found in the MSL document, but with a different syntax, would allow us to reference any schema type in XQuery function definitions.
Text is in Working Draft 2001-11-28 sec 3.
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.
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.
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?
As part of the general description of errors, which is largely still to be done, we must carefully distinguish static from dynamic errors. In general, we should probably attempt to catch errors as early as possible. The following examples have been suggested by the Algebra team:
"If the content of its argument node cannot be expressed as a value of a simple type, the data function raises an error." This could be a static error, since the data function makes most sense for schema valid documents or nodes that have type assigned via xsi:type.
"For each member of the sequence, the ordering expression must return a single value of some type for which the ">" operator is defined (for example, a number or a string); otherwise an error results." This could also be a static error.
"When one or more operands is a node, the content of the node is extracted by an implicit call to the data function and converted to a number before the operation is performed; if this conversion is not possible, an error results." This could be a static or a dynamic error.
"TO is a binary operator that converts both of its operands to integers. It then generates a sequence containing all the integers from the left-hand operand to the right-hand operand, inclusive. If either of the operands cannot be converted to an integer, an error results." In the presence of type info, this could be a static error. In a well-formed document, in which arbitrary strings may be converted to integers, it could be dynamic.
Text is in Working Draft 2001-11-28 sec 3.
The Algebra has a syntax for declaring types. Up to now, XQuery uses XML Schema for declaring types. Is this sufficient? Some important questions:
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://www.example.com/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")
We do not specify how a Schema or DTD is 'imported' into a query so that its information is available during type checking. Schema and DTDs can either be named explicitly (e.g., by an 'IMPORT SCHEMA' clause in a query) or implicitly, by accessing documents that refer to a Schema or DTD. The mechanism for statically accessing a Schema or DTD is unspecified.
This item is a duplicate of the Formal Semantics issue [link to member only information] .
Text is in Working Draft 2001-11-28 sec 3.
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?
In the XQuery Formalism document, there is a static type-assertion expression:
Expr : Type
This is often useful in an expression like:
LET bib0 : Bib := <bib>...some literal data...</bib>
which asserts statically that the type of bib0 is Bib, i.e., that the literal data is a value contained in the Bib type. If this is not true, a static, compile-time error is raised.
This semantics is not the same as :
LET bib0 := TREAT AS Bib (<bib>...</bib>)
which will raise a run-time error if the literal data is not a value in Bib.
Current proposal is for ASSERT AS Datatype (Expr)
Text is in Working Draft 2001-11-28 sec 2.13.
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?
Decision by: xpath-tf on 2001-11-06 ([link to member only information] )
Decision by: xsl on 2001-11-29 ([link to member only information] )
Addressed by Mike K's text in [link to member only information]
Text is in Working Draft 2001-11-28 sec 2.1.1.2, paragraph 4.
Do we need a way to specify the nodes in the input context? Many queries do not specifically state the input to which they will be applied. This allows the same query, for instance, to be applied to a number of databases. It may be helpful for the mapping to introduce a global variable, eg $input, to represent the input nodes for a query. This variable might even be useful in the syntax of XQuery itself.
It seems like the context should include a default namespace declaration for use for the QNames within node tests within the XPath. I'm worried about complexities with other qnames besides the one in node tests, like function qnames.
Decision by: xpath-tf on 2001-11-06 ([link to member only information] )
Decision by: xsl on 2001-11-29 ([link to member only information] )
Addressed by Mike K's text in [link to member only information]
Text is in Working Draft 2001-11-28 sec 2.1.1.1, paragraph 5.
Do we need a datatype names binding in the context?
Decision by: xpath-tf on 2001-11-06 ([link to member only information] )
Decision by: xsl on 2001-11-29 ([link to member only information] )
Addressed by Mike K's text in [link to member only information]
Text is in Working Draft 2001-11-28 sec 2.1.1.1, paragraph 8.
The Functions and Operators doc specifies named collations. These probably need to be part of the context. 1) Should we treat collations as distinct from functions? 2) If yes, how do we handle the binding of the collation name to the collation.
Decision by: xpath-tf on 2001-11-06 ([link to member only information] )
Decision by: xsl on 2001-11-29 ([link to member only information] )
Addressed by Mike K's text in [link to member only information]
Text is in Working Draft 2001-11-28 sec 2.1.1.1, paragraph 11.
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.
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?
There is no operator to access the typed constant content of an element. In the Algebra, the data() operator does this. Should XQuery do the same?
Decision by: xpath-tf on 2001-10-23 ([link to member only information] )
Decision by: xquery on 2001-10-31 ([link to member only information] )
Decision by: xsl on 2001-12-13 ([link to member only information] ) It was noted that there are other issues on data() that may lead to further discussions.
Consensus is to define data() on only singleton node and empty sequence. This decision will be reflected in next WD.
Section 1 - 4th paragraph says the typed-value of an element with complex type is the same as its string-value. This is not currently consistent with the data model. The data model doc says, in section 4.2, "If the element has a complex type, the typed-value is the empty sequence. For an element in a well-formed document with no associated schema, the element's typed-value is the empty sequence."
Ed. Note: Question: I had a note from this, "insert from minutes", but I only see "Need to track "what does data()" return as an issue. Typed value? Something else?" as a response to this issue, and the formulation of issue text for the Data Model. Should this issue be removed from this document? -sb
Do we need an identity-based equality operator? Please justify your answer with sample queries. Note that XPath gets along without it.
The '==' operator is already defined in the F&O document and used in XQuery use cases.
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.
Text is in Working Draft 2001-11-28 sec 2.4.
In XPath 1.0, string1 = string2 is evaluated by string comparison, but string1 > string2 is evaluated by attempting to convert both strings to floating-point numbers and comparing the numbers. This seems inconsistent. Both of these comparions should be carried out as string comparisons using the default collation.
In XPath 1.0, comparison of a string with a number is carried out by attempting to convert the string to a number. For example, 47 = "47" is True. This seems to conflict with strong typing. One might expect 47 = "47" to be a type error. Status: Open, pending discussion.
Addressed by XPath 2.0 basic and standard-fallback conversions.
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?
The note "NOTE: The string operators will be backwards > compatible with XPath 1.0 ...." is true only in the case of the <, >, <=, > and >= operators. It's not true for "=" and "!=". In fact, if this collating > sequence is used, then < will be compatible ("1" <= "1.0" is true) but "=" > will not be compatible ("1" = "1.0" is now true, previously false).
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.
Dana Florescu has been assigned the task of writing a proposal for this.
Are an empty sequence and an empty node-set distinguishable?
The data model does not distinguish between sequences and between 'node sets', i.e., sequences in document order with no duplicates, therefore there is only one empty sequence.
XQuery-Null-Issue-7: Question: What should happen if a function expecting one element is invoked on an empty sequence?
It's an error.
Text is in Working Draft 2001-11-28 sec 2.1.2, paragraph 6, item 1.3.
What should the the result of various aggregate functions when applied to the empty sequence?
As in SQL, count(()) returns 0, and all other aggregate functions return the empty sequence. This rule is familiar to SQL users and minimizes the complexity of SQL-based XQuery implementations.
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.
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: Axis subsetting should be done at the grammar level, similar to how XSLT pattern matching is specified.
XPath supports 13 axes. The current Working Draft says that XQuery will support a subset of these axes, including at least those axes required by the abbreviated syntax. The definitive set of axes to be supported by XQuery has not yet been determined. In the current Working Draft, the examples use abbreviated syntax, but the grammar supports unabbreviated syntax.
For the axes required by the abbreviated syntax, should XQuery allow both the unabbreviated and abbreviated syntax? If we decide not to support additional axes, no new functionality would be added by supporting the unabbreviated syntax. Opinions vary as to whether the unabbreviated syntax is clearer.
Text is in Working Draft 2001-11-28 sec 2.3.
The XPath task force has recommended that we allow any expression in a path step. Proponents note that this adds to the symmetry of the language. Opponents note that this allows queries to be written that are very difficult to read, and may raise some issues for optimization. This needs further study.
Text is in Working Draft 2001-11-28 sec 2.3.
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.
The division of path expressions into relative and absolute isn't reflected in the syntax. I think it's best to define the semantics as follows: / is an abbreviation for root(), /expr is an abbreviation for root()/expr, and // is an abbreviation for "/descendant-or-self::node()/". If the first step is an AxisStepExpr, add "./" in front of the expression. All unabbreviated paths now take the form OtherStepExpr ( '/' StepExpr )* and we only need to define the semantics of this kind of path expression.
We need functions to return the name of an attribute and the content of an attribute.
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.
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?
Text is in Working Draft 2001-11-28 sec 2.3.
We need a function for constructing attributes.
The attribute function takes two parameters. The first is the name of the attribute to be constructed. The second is the value of the attribute to be constructed. If an attribute function occurs within an element constructor, the attribute is added to the set of attributes for that element.
<foo> IF $f/temp > 200 THEN make_attribute("warning", "about to explode!!") ELSE [] </foo></foo>
Note Dana and Phil's exchange re: typing when attribute names are not statically known.
XQuery currently allows computed attribute values without quotes, which is not well-formed XML:
<foo bar={//baz} />
In XSLT, the equivalent syntax uses quotes:
<foo bar="{//baz}" />
Should XQuery adopt the XSLT convention? This would make it easier for XQuery to reside in well formed XML documents.
Text is in Working Draft 2001-11-28 sec 2.8.
The current syntax for computed elements and attributes uses a syntax that looks like XML but is not well-formed XML.
<{name($e)}> # replicates the name of $e {$e/@*} # replicates the attributes of $e {2 * number($e)} # doubles the content of $e </>
This makes it hard to embed queries that use this syntax in well-formed XML documents. Also, the Formal Description uses a syntax for element and attribute construction that is more suitable for use with inference notation. Should an alternative construction syntax be used that eliminates both problems?
Text is in Working Draft 2001-11-28 sec 2.8.
Is there a need for a constructor that creates an instance of the XML Query Data Model from a string that contains XML text?
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?
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?
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.
What does <a b={expr}> mean if expr returns an empty sequence? Option 10A: Attribute is not created. Option 10B: Run-time error. Option 10C: The attribute is created, and its value is the empty sequence. Option 10D: The attribute is created and its value is the empty sequence if this is allowed by the attribute type; otherwise it's a run-time error. Option 10E: The attribute is created and its value is the empty sequence. However, an error may occur when the attribute is serialized. Option 10F: If the attribute-type is a list of scalar types that allows the empty list, an attribute is created with an empty sequence as its value; if the attribute is optional and scalar, then the attribute is not created. If the type system does not allow the attribute to be an empty list or absent, a type error is raised.
Decision by: xquery on 2001-12-07 ([link to member only information] )
Adopt 10C.
If an element constructor contains a namespace declaration in XML syntax, is the namespace declared in the query?
<foo:bar xmlns:foo="//www.foo.com/foo.xsd"> <foo:baz> Is this baz in the 'www.foo.com' namespace? </foo:baz> </foo>
Text is in Working Draft 2001-11-28 sec 2.8.
The ORDERBY operator of XQuery can be used to order a sequence of elements by some computed expression which may return an empty value. What is the resulting order? For example, in the query //emp SORTBY bonus, what is the position of employees who have no bonus? Option 15A: Implementation-defined, but a given implementation must sort all the values with an empty sort-key consistently either first or last (as in SQL). Option 15B: Empty sort-keys always sort first. Option 15C: Empty sort-keys always sort last. Option 15D: Invent some syntax to specify how empty sort-keys should be handled.
Text is in Working Draft 2001-11-28 sec 2.10.
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?
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.
If a function name is not qualified by a namespace prefix, what namespace is the function in? Some options that have been suggested: the function might be considered to be in no namespace, in a default namespace, or in the namespace of XQuery's built-in functions.
Text is in Working Draft 2001-11-28 sec 3.
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.
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?
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.
How do we exclude undesired elements from the results of joins?
[link to member only information] :
This need came out of a thread exploring data integration scenarios, starting with http://lists.w3.org/Archives/Member/w3c-archive/2000Dec/0132.html.
If we have polymorphism in the operator, should we have only one fallback?
Matching Operands with Polymorphic Operators Consider the operator +. Assume, purely for illustration, that + is defined on numerics, strings and a date and a duration. When the interpreter sees "op1 + op2" how does it decide what function to call. Here are the rules by example for +: - If op1 and op2 are numerics it accepts the operands and calls the appropriate function based on the numeric promotion rules described below. - If op1 and op2 are strings it accepts the operands, converts both operands to string and calls the string-concat function. - It then checks if the first operand is a date and the second operand is a duration. If so, it calls the add-duration-to-date function. - If none of the above rules works a type exception is declared. Depending on the host language and the environment (as indicated by a global variable) one of two actions occurs: o A fallback conversion is attempted. Fallback conversions are described in detail in the XPath straw document o A type error is declared. When an error is declared the process aborts. This means that functions never have to deal with error inputs. This is a logical specification of how the process works. Implementations are free to create implementations that differ from the above as long as they obey the semantics defined in the F&O document. For example, 10 div 3 should return 3. Numeric Type Promotions For simplicity, each operator is defined to operate on operands of the same type and to return the same type. If the two operands are not of the same type, one operand is promoted to be the type of the other operand. Numeric types have the following hierarchy : integer->decimal->float->double Note that we need to take user-defined types into account. For example, a user may define height as a derived type of integer with a minimum value of 20 and a maximum value of 100. He may then derive oddHeight using a pattern to restrict the value to odd integers. If op1 is of type oddHeight. We first promote it to its base type, integer. If op1 and op2 are now both integers we call addInteger or whatever the appropriate function is. If not, we see which of the operators is higher in the above hierarchy and promote the other until we get two integers or two decimals or two floats or two doubles. This is guaranteed to occur. Then we call the appropriate functions for the operands. The F&O document contains details of numeric type promotions.
Text is in Working Draft 2001-11-28 sec 2.5.
Do we still need fallbacks if we have a marker for untyped data (="PCDATA")?
[link to member only information] Mary F. Fernandez:
Text is in Working Draft 2001-11-28 sec 2.5.
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.
The mapping from operators (such as "+", "*") to the operator functions needs to be defined. A second question is if the text should be in the F&O or XPath/XQuery document.
This belongs in the XPath document. Ashok will send a draft to Don, who will incorporate this in XPath post December 2001 publication.
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.
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.
Union, intersect, and except on node sequences are defined to return their results in document order.
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.
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.
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.
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.
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. [!]
Is it legal to use names that lexically match a QName if the prefix has not been bound in a namespace declaration?
Issue is for material in sec 3. in Working Draft 2001-11-28.
Statement that using a namespace prefix that has not been declared is an error.
If a function parameter does not specify a type, can both nodes and values be passed as arguments? If a function return does not specify a type, can both nodes and values be returned?
Issue is for material in sec 3. in Working Draft 2001-11-28.
The default type of a function parameter when no type is specified in the function signature is changed from "any node" to "any type". The default return type of a function when no return type is specified is changed from "any sequence of nodes" to "any type".
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.
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?
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.
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
Should namespace prefixes apply equally to nametests, element and attribute construction, variables, and functions? Consider the following example:
<foo xmlns:bar="http://www.foo.com"> { bar:sort(1,2,3) } </foo>
Is bar:sort() in the namespace defined by the xmlns attribute?
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?
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?
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.
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.
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.
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.
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.
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.
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.
Document had been completely rewritten during the joint work on XPath (see text in Intro).
The following issues have been resolved:
Should not( () ) == true or () or not3 function be defined? Section 2.7 Logical Expressions
Do we really require for
at the XPath expression
level? Section 2.9 FLWR Expressions
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.Section 2.13 Datatypes
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?Section 2.1.1.2 Evaluation Context
Does the context include a default namespace declaration? Section 2.1.1.1 Static Context
Do we need a datatype names binding in the context? Section 2.1.1.1 Static Context
How should qname-to-collation bindings be handled?Section 2.1.1.1 Static Context
Implied existential quantifiersSection 2.6.1 Value Comparisons
Functions on Empty Sequences... What should happen if a function expecting one element is invoked on an empty sequence?Section 2.1.2 Type Conversions
Functions on Sequences... What should happen if a function expecting one element is invoked on a sequence of more than one element? Section 2.1.2 Type Conversions
Path iteration... How should the current node be passed to a function in a path-step?Section 2.1.1.2 Evaluation Context
Should we use is and isnot instead of == and !==. Section 2.6.2 General Comparisons
Semantics of positional predicates in XPath Section 2.3.3.1 Predicates
Function call rules needed Section 2.1.2 Type Conversions