XQuery 1.0: An XML Query Language

2.1.1 Expression Context

The expression context for a given expression consists of all the information that can affect the result of the expression. This information is organized into two categories called the static context and the evaluation context.

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

2.1.2 Type Conversions

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:

1. If the required type is a simple type or an optional occurrence of a simple type:

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

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

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

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

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

2.2.1 Literals

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

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.

2.2.2 Variables

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.

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.

2.2.3 Parenthesized Expressions

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.

2.2.4 Function Calls

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.

A function call expression is evaluated as follows:

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

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

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

2.2.5 Comments

Comments can be used to annotate a query with informative information. Comments are lexical constructs only, and have no meaning within the query.

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.

2.3.1 Axis Steps

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

2.3.2 General Steps

In addition to the axis step format described above, a step in a path expression may take another form, called a general step.

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

2.3.3 Step Qualifiers

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.

2.3.4 Unabbreviated Syntax

This section provides a number of examples of path expressions in which the axis is explicitly specified in each step. The syntax used in these examples is called the unabbreviated syntax. In many common cases, it is possible to write path expressions more concisely using an abbreviated syntax, as explained in 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

2.3.5 Abbreviated Syntax

The abbreviated syntax permits the following abbreviations:

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

2. There is also an abbreviation for attributes: attribute:: can be abbreviated 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.

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

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

4. A step consisting of . 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.

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

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

• para selects the para element children of the context node

• * selects all element children of the context node

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

• @name selects the name attribute of the context node

• @* selects all the attributes of the context node

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

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

2.4.1 Constructing Sequences

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)

2.4.2 Combining Sequences

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.

2.6.1 Value Comparisons

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

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

2. If either operand is a sequence containing more than one item, an error is raised.

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

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

5. The result of the comparison is true if the value of the first operand is (equal, not equal, less than, less than or equal, greater than, greater than or equal) to the value of the second operand; otherwise the result of the comparison is false. [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"

2.6.2 General Comparisons

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

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

Similarly:

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

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

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

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

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

Here is an example of a general comparison:

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

  $book1/author = "Kennedy"

2.6.3 Node Comparisons

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

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

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

3. A comparison with the == operator 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"]

2.6.4 Order Comparisons

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

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

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

3. A comparison with the << operator returns true if the first operand node is earlier than the second operand node in document order, or false if the first operand node is later than the second operand node in document order.

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

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

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

2.8.1 Element Constructors

An element constructor creates an XML element. If the name, attributes, and content of the element are all constants, the element constructor 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.

2.8.2 Computed Element and Attribute Constructors

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.

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>

2.8.3 Other Constructors and Comments

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

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