XQuery Scripting Extension 1.0

2.1 Evaluation Order

[Definition: XQSX defines an evaluation order on many kinds of XQuery expressions, which is the order that operand expressions must be evaluated in order to determine what side-effects are visible to later expressions.] An implementation may use any execution strategy as long as the result complies with the semantics of this ordering.

2.2 Snapshot and Execution Scope

The term snapshot is defined in [XQuery Update Facility] as follows: [Definition: A snapshot is a scope within which expressions are evaluated with respect to a fixed XDM instance and updates are held pending.] A snapshot is terminated by invocation of the upd:applyUpdates operation. Unlike XQUF, XQSX permits a query to contain more than one snapshot.

[XQuery 1.0 and XPath 2.0 Functions and Operators] defines certain functions as stable^FO. Stable functions such as fn:current-time and fn:doc are defined to return the same result given the same arguments within an execution scope^FO. XQSX redefines the extent of an execution scope, so that a top level query can contain many execution scopes.

In XQSX, each of the following expressions is both a snapshot and execution scope:

• each ConcatExpr within an ApplyExpr

• each initialization expression in a BlockVarDecl

• the expression on the right-hand side of an AssignmentExpr

• the expression in an ExitExpr

• the test expression in a WhileExpr

2.3 Variable Binding Revalidation

To ensure type soundness, variable bindings are revalidated at the end of each scope to check that any updates applied have not made them invalid with repect to their declared types. It is a dynamic error [err:SXDY0003] if, after applying a pending update list (using upd:applyUpdates), the XDM instance bound to any in-scope variable does not match the static type of that variable according to SequenceType matching rules.

2.4 Updating Expression Constraints

XQSX relaxes the constraints on the placement of updating expressions, so that a non-empty XDM instance can be returned by an expression as well as a non-empty pending update list. In order to allow this, new rules to determine the category and resulting pending update list are added to every existing expression, following certain principles:

• An updating expression is allowed anywhere a simple expression is allowed. If an operand of an expression is an updating expression, the expression itself is an updating expression.

• An expression may not be both sequential and updating. If an updating expression contains or uses a sequential expression (or vice versa), an error is raised [err:SXST0002].

• The pending update list that results from any given expression is the result of calling upd:mergeUpdates on the pending update lists from the result of all of its operand expressions. No pending update list is ever discarded.

2.5 Sequential Expressions

XQSX introduces a new expression category called sequential expressions. The simple and updating expression categories introduced by XQUF are retained, but the vacuous expression category no longer has significance. Informal definitions of all the expression categories are summarized here. For normative definitions of the categories, see the "Category Rules" that are specified for each kind of expression in [5 New Kinds of Expressions] and [6 Changes to Existing Expressions].

1. [Definition: An updating expression is an expression that can return a non-empty pending update list.] Updating expressions include insert, delete, replace, rename, and calls to updating functions, as well as certain other expressions that contain nested updating expressions. An updating expression may return a non-empty XDM instance as well as a non-empty pending update list - however note that it does not actually apply any updates.

2. [Definition: A sequential expression is an expression that can have side effects other than constructing a new node or raising an error.] Side effects include applying updates to an XDM instance, altering the dynamic context, or affecting the flow of control. Sequential expressions include apply expressions, assignment, exit, while, and calls to sequential functions, as well as certain other expressions that contain nested sequential expressions. The side effects of a sequential expression are immediately effective and are visible to subsequent expressions. Because of their side effects, sequential expressions must be evaluated in a well-defined order. In addition to its side effects, a sequential expression may return a non-empty XDM instance, but it never returns a non-empty pending update list.

3. [Definition: A simple expression is an expression that is neither an updating expression nor a sequential expression.] A simple expression may return an XDM instance, and it may construct a node or raise an error.

The classification of each expression into one of the above categories is performed by static analysis. For each kind of expression, XQSX provides rules that specify the required categories of the operand expressions and the category of the expression itself.

Note that simple expressions, updating expressions, and sequential expressions are disjoint categories. The kinds of values that can be returned by the various expression categories are summarized in the following table:

3.1 Predefined Namespace

XQSX adds the pair (xqsx, http://www.w3.org/2008/xquery-sx-10) as a predefined namespace to the statically known namespaces.

3.2 Query Mode

[Definition: The query mode governs the composability of updating and sequential expressions. Valid values are sequential and simple.] The default initial value of query mode is sequential, but it can be overwritten by an implementation. Query mode has a lexical scope, and can be modified at both the module and expression level.

In particular, query mode affects the category rules for [6.3 Path Expressions], [6.4 Predicates], [6.7 FLWOR Expressions], and [6.9 Quantified Expressions].

4.1 Assignable Global Variables

XQSX allows the qualifiers assignable and unassignable to be used in a Prolog variable declaration. [Definition: Prolog variables declared as assignable may have their value changed by an [5.3 Assignment Expression].] If an assignment qualifier is not used, the default is unassignable.

The semantics of assignable variables are the same as the semantics of unassignable variables, except that the static type of an assignable variable without a declared type is always item()*.

The initializing expression of a prolog variable (whether assignable or not) must be a simple expression [err:XUST0001].

4.2 Function Declarations

Definitions:

[Definition: A simple function is a function whose declaration specifies neither updating nor sequential. A simple function may optionally specify the keyword simple.]

[Definition: An updating function is a function whose declaration specifies the keyword updating.]

[Definition: A sequential function is a function whose declaration specifies the keyword sequential.]

Category Rules:

• If the body of a simple function is an EnclosedExpr, it must be a simple expression.

• If the body of an updating function is an EnclosedExpr, it must be either an updating or simple expression.

• If the body of a sequential function is a Block it must be either a sequential or simple expression.

• If the body of a function violates the category rules for it's declared category, [err:SXST0008] is raised.

Semantics:

The semantics of simple functions are defined in [XQuery Update Facility] and [XQuery 1.0], and remain unchanged in XQSX.

The semantics of updating functions as originally defined in [XQuery Update Facility] are extended as follows:

• A return type is permitted.

• If external is specified, the external function may return both a non-empty pending update list and a non-empty XDM instance.

• If the result of an updating function does not match its declared result type (after applying function conversion rules as specified in Section 3.1.5 Function Calls^XQ), a type error is raised [err:XPTY0004]^XQ. The default result type of an updating function is item()*.

The semantics of sequential functions are as follows:

• The result of a sequential function is determined by the first [5.5 Exit Expression] encountered during evaluation of the Block. If no exit expression is encountered, the result of the function is the value returned by the Block that comprises its body.

• If the result of a sequential function does not match its declared result type (after applying function conversion rules as specified in Section 3.1.5 Function Calls^XQ), a type error is raised [err:XPTY0004]^XQ. The default result type of a sequential function is item()*.

• If a sequential function is declared external, its implementation is outside the XQuery environment. The means by which parameters are passed to an external function and its result is returned to the calling expression are implementation-defined. An external sequential function may not return a non-empty pending update list [err:SXDY0004].

4.3 Query Mode Option

XQSX defines the QName xqsx:query-mode as a well-known option name for use in an OptionDecl, which sets the query mode in the static context for the module to the value specified. A static error is raised [err:SXST0009] if the value for a xqsx:query-mode option is not either sequential or simple.

Implementations of XQSX must recognize the option namespace URI http://www.w3.org/2008/xquery-sx-10, and the option xqsx:query-mode.

5.1 Apply Expression

Category Rules:

[Definition: An apply expression is a list of semicolon-terminated ConcatExpr productions, called operand expressions. An ApplyExpr consisting of a single ConcatExpr with no semicolon is not an apply expression.] An apply expression is a sequential expression.

The operands of the apply expression may be an expression of any category.

Semantics:

The operand expressions of an apply expression are evaluated in the order they appear. After the evaluation of each operand expression, the pending update list returned by the expression is applied (by upd:applyUpdates). The XDM instance returned by all expressions other than the last one is discarded. The side effects of each expression are visible during the evaluation of subsequent expressions.

The result of the apply expression is the XDM instance returned by the last operand expression, and an empty pending update list.

5.2 Block Expressions

Category Rules:

[Definition: The expression on the right-hand side of a block variable declaration is called an initializing expression.] Initializing expressions may be in any category.

Note:

Block variable declarations, unlike Prolog variable declarations, permit their initializing expressions to be updating or sequential expressions.

If a BlockExpr contains initializing expressions that are either updating or sequential expression, then the BlockExpr is a sequential expression. In this case the BlockBody must be either a simple or sequential expression, otherwise a static error [err:SXST0002] is raised.

If a BlockExpr only contains initializing expressions that are simple expressions (or contains no initializing expressions), then the BlockBody may be an expression of any category. In this case the BlockExpr has the same category as the BlockBody.

Semantics:

A block consists of zero or more block variable declarations followed by a body. Each block variable declaration defines a modifiable local variable whose scope is the remainder of the block (not including its initializing expression). The variable defined in a block variable declaration occludes (hides) any variable of the same name that is in scope at the location where the block appears.

It is a static error [err:SXST0005] if two or more variables declared in the same block have the same expanded QName.

The type of each declared variable is added to in-scope variables in the static context. If no explicit type is declared, the type of the variable is item()*. If a variable has both an explicit type declaration and an initializing expression, the value of the initializing expression must match the declared type according to SequenceType matching rules; otherwise a type error is raised [err:XPTY0004]^XQ.

The block variable declarations are evaluated in the order written. The block variable declaration evaluates its initializing expression and adds the resulting XDM instance to the variable values in the dynamic context. Any pending update list returned is applied using upd:applyUpdates. If no initializing expression is present, the variable has no initial value. A reference to a variable, other than on the left-hand side of an assignment expression, is an error if the variable has no value in variable values when the reference is evaluated [err:SXTY0006].

After all the block variable declarations have been evaluated, the BlockBody expression is evaluated. The result of the block expression is the XDM instance and pending update list returned by the BlockBody.

5.3 Assignment Expression

Category Rules:

An assignment expression is a sequential expression.

Semantics:

The variable on the left-hand side of the assignment must have been declared in one of the following ways, otherwise a static error [err:SXST0007] is raised:

• By a block variable declaration

• As a parameter to a sequential function

• By a variable declaration in the Prolog declared as assignable

In all cases the variable must be in the in-scope variables, otherwise a static error is raised [err:XPST0008]^XQ.

Note:

Variables bound in FLWOR, typeswitch, or quantified expressions may not appear on the left-hand side of an assignment.

The expression on the right-hand side is evaluated, resulting in an XDM instance and a pending update list.

If the XDM instance returned by the expression on the right-hand side does not match the declared type of the variable according to SequenceType matching rules, a type error is raised [err:XPTY0004]^XQ. If the types match, the XDM instance returned by the expression is bound to the variable (added to variable values in the dynamic context.)

The pending update list returned by the expression on the right-hand side is applied using upd:applyUpdates.

The result of an Assignment Expression is an empty XDM instance and an empty pending update list.

5.4 While Expression

Category Rules:

[Definition: The expression enclosed in the parentheses of a while expression is called a test expression.] The test expression may be in any category.

A static error [err:SXST0002] is raised if the WhileBody is an updating expression.

A while expression is a sequential expression.

Semantics:

The while expression is used for conditional iteration. It is evaluated as follows:

The test expression is evaluated, resulting in an XDM instance and a pending update list. The pending update list returned by the test expression is applied using upd:applyUpdates.

If the effective Boolean value of the test expression is false, the block is not evaluated. If the effective Boolean value of the test expression is true, the block is evaluated repeatedly. Each evaluation of the block may cause side effects that affect the result of re-evaluating the test expression. The test expression is re-evaluated after each evaluation of the block. This process continues until the effective Boolean value of the test expression is evaluated to be false.

The result of a while expression is an empty XDM instance and an empty pending update list.

Example:

In the following query, a while expression is used to compute a sequence containing all the Fibonacci numbers that are less than 100.

block {
  declare $a as xs:integer := 0;
  declare $b as xs:integer := 1;  
  declare $c as xs:integer := $a + $b;
  declare $fibseq as xs:integer* := ($a, $b);
 
  while ($c < 100) { 
     $fibseq := ($fibseq, $c);
     $a := $b;
     $b := $c;
     $c := $a + $b;
  };

  $fibseq;
}

5.5 Exit Expression

Category Rules:

The operand of an exit expression may be an expression of any category.

An exit expression is a sequential expression.

Semantics:

An exit expression serves to define the result of the enclosing function or query body.

The operand expression of the exit expression is evaluated, resulting in an XDM instance and a pending update list. The pending update list returned by the operand expression is applied using upd:applyUpdates.

If an exit expression is evaluated within the body of a function, further evaluation of the function body is interrupted and the XDM instance returned by the operand expression is returned as the result of the function call.

If an exit expression is evaluated within a query body (i.e., not within the body of a function), further evaluation of the query is interrupted and the XDM instance returned by the operand expression is returned as the result of the query.

Note:

An exit expression in a block terminates evaluation of the enclosing function body or query, not just the immediately enclosing block.

5.6 Query Mode Pragma

XQSX defines the QName xqsx:query-mode as a well-known pragma name for use in an ExtensionExpr, which sets the query mode in the static context for the enclosed expression to the value specified. A static error is raised [err:SXST0009] if the value for a xqsx:query-mode pragma is not either sequential or simple.

Implementations of XQSX must recognize the pragma namespace URI http://www.w3.org/2008/xquery-sx-10, and the pragma name xqsx:query-mode.

6.1 Parentheses

Category Rules:

An expression of any category may be enclosed in parentheses; the resulting expression has the same category as the original expression. An empty parenthesized expression ( ) is a simple expression.

6.2 Function Calls

Category Rules:

If the function called is a simple function, the argument expressions can either be all simple and updating expressions, or all simple and sequential expressions. If the argument expressions contain an updating expression then the function call is an updating expression, if they contain a sequential expression then the function call is a sequential expression, otherwise it is a simple expression.

If the function called is an updating function, the argument expressions must be simple expressions or updating expressions. The function call is an updating expression.

If the function called is a sequential function, the argument expressions must be simple expressions or sequential expressions . The function call expression is a sequential expression.

If the arguments of a function call violate the category rules for the function's category, [err:SXST0002] is raised.

Evaluation Order:

Argument expressions are evaluated from left to right, then the function is invoked.

Additional Semantics:

The pending update lists returned by the argument expressions are merged with the pending update list returned by the function itself by calling upd:mergeUpdates.

6.3 Path Expressions

Category Rules:

The category of a path expression is determined by the following rules:

• If query mode is simple, [err:XUST0001] is raised if any StepExpr in the RelativePathExpr is an updating or sequential expression.

• If any StepExpr in the RelativePathExpr is an updating expression, then all StepExpr must be updating or simple expressions, otherwise a static error is raised [err:SXST0002]. In this case, the path expression is an updating expression.

• If any StepExpr in the RelativePathExpr is a sequential expression, then all StepExpr must be sequential or simple expressions, otherwise a static error is raised [err:SXST0002]. In this case, the path expression is a sequential expression.

• Otherwise, the path expression is a simple expression.

Evaluation Order:

StepExpr are evaluated in order from left to right.

Additional Semantics:

The pending update lists returned by each of the StepExpr are merged by calling upd:mergeUpdates, and returned as part of the result of the path expression.

6.4 Predicates

Category Rules:

The category of a FilterExpr or AxisStep is determined by the following rules:

• If query mode is simple, [err:XUST0001] is raised if the primary expression or a predicate expression of any FilterExpr or AxisStep is an updating or sequential expression.

• If either the primary expression or any predicate expression of a FilterExpr or AxisStep is an updating expression, then all such expressions must be updating or simple expressions, otherwise a static error is raised [err:SXST0002]. In this case, the FilterExpr or AxisStep is an updating expression.

• If either the primary expression or any predicate expression of a FilterExpr or AxisStep is a sequential expression, then all such expressions must be sequential or simple expressions, otherwise a static error is raised [err:SXST0002]. In this case, the FilterExpr or AxisStep is a sequential expression.

• Otherwise, the FilterExpr or AxisStep is a simple expression.

Evaluation Order:

First the reverse step, forward step or primary expression is evaluated, then predicates are evaluated from left to right. Each predicate expression must be evaluated to completion before the next is evaluated.

Additional Semantics:

The pending update list returned by the primary expression is merged with the pending update lists returned by the predicate expressions by calling upd:mergeUpdates. The resulting pending update list is returned as part of the result of the FilterExpr or AxisStep.

6.5 Concatenation Expressions

Category Rules:

The category of a concatenation expression is determined by the following rules:

• If any operand is an updating expression, then all operands must be updating or simple expressions, otherwise a static error is raised [err:SXST0002]. In this case, the concatenation expression is an updating expression.

• If any operand is a sequential expression, then all operands must be sequential or simple expressions, otherwise a static error is raised [err:SXST0002]. In this case, the concatenation expression is a sequential expression.

• Otherwise, the concatenation expression is a simple expression.

Evaluation Order:

Operand expressions are evaluated once, from left to right. Side effects of each sequential operand expression are visible to subsequent operand expressions.

Additional Semantics:

The concatenation expression evaluates each of its operands and concatenates the resulting XDM instances and pending update lists, in order. Pending update lists are concatenated by the upd:mergeUpdates operation.

6.6 Direct and Computed Node Constructors

Category Rules:

The category of a node constructor is determined by the following rules:

• If any operand is an updating expression, then all operands must be updating or simple expressions, otherwise a static error is raised [err:SXST0002]. In this case, the node constructor is an updating expression.

• If any operand is a sequential expression, then all operands must be sequential or simple expressions, otherwise a static error is raised [err:SXST0002]. In this case, the node constructor is a sequential expression.

• Otherwise, the node constructor is a simple expression.

Evaluation Order:

1. The name expression is evaluated (computed element/attribute/processing-instruction constructors only).

2. The direct attribute constructors are evaluated from left to right (direct element constructors only).

3. The child or value expressions are evaluated from left to right.

Additional Semantics:

The pending update lists from each operand expression are concatenated by the upd:mergeUpdates operation, producing the resulting pending update list.

6.7 FLWOR Expressions

Category Rules:

The for, let, where, and order by clauses can either be all simple and updating expressions, or all simple and sequential expressions.

• If query mode is simple, [err:XUST0001] is raised if any for, let, where, or order by clause is an updating or sequential expression.

• If the above clauses contain an updating expression, then all clauses must either be a simple expression or an updating expression, otherwise a static error is raised [err:SXST0002]. The FLWOR expression itself is an updating expression.

• If the above clauses contain a sequential expression, then all clauses must either be a simple expression or an sequential expression, otherwise a static error is raised [err:SXST0002]. The FLWOR expression itself is an sequential expression.

• If the above clauses do not contain an updating expression or a sequential expression, then the return clause may be an expression of any category. The category of the FLWOR expression is the same as the category of the expression in its return clause.

Evaluation Order:

• For Clause: The associated expression is evaluated first to produce the binding sequnce, then the next clause is evaluated once for each item in the binding sequence. Any side effects in the associated expression are visible to the evaluation of the next clause.

• Let Clause: The associated expression is evaluated first to produce the binding sequnce, then the next clause is evaluated. Any side effects in the associated expression are visible to the evaluation of the next clause.

• Where Clause: The where expression is evaluated once, then the next clause is evaluated. Any side effects in the where expression are visible to the evaluation of the next clause.

• Order By Clause: The orderspecs are evaluated from left to right on each tuple in the tuple stream. The tuple stream is reordered, then the next clause is evaluated.

• Return Clause: The return expresion is evaluated once.

Additional Semantics:

The result of a FLWOR expression is the concatenation of the XDM instances or pending update lists returned by successive evaluations of the return clause in evaluation order, as well as the pending update lists returned by any of the other FLWOR clauses. Pending update lists are concatenated by the upd:mergeUpdates operation.

6.8 Conditional Expressions

Category Rules:

The test, then and else expressions can be of any type. An error [err:SXST0002] is raised if one of the expressions is updating and another is sequential.

• If the test, then or else expression is an updating expression, the conditional expression is an updating expression.

• If the test, then or else expression is a sequential expression, the conditional expression is a sequential expression.

• Otherise, the conditional expression is a simple expression.

Evaluation Order:

The test expression is evaluated first. Next either the then expression or the else expression (but not both) is evaluated.

Additional Semantics:

The pending update list returned by the conditional expression is calculated by merging the pending update lists from the test expression and the executed branch of the conditional expression using upd:mergeUpdates.

6.9 Quantified Expressions

Category Rules:

The category of a quantified expression is determined by the following rules:

• If query mode is simple, [err:XUST0001] is raised if any quantified expression clause or the satisfies expression is an updating or sequential expression.

• If any quantified expression clause or the satisfies expression is an updating expression, then all such expressions must be updating or simple expressions, otherwise a static error is raised [err:SXST0002]. In this case, the quantified expression is an updating expression.

• If any quantified expression clause or the satisfies expression is a sequential expression, then all such expressions must be sequential or simple expressions, otherwise a static error is raised [err:SXST0002]. In this case, the quantified expression is a sequential expression.

• Otherwise, the quantified expression is a simple expression.

Evaluation Order:

The quantified expression clauses are initially evaluated as specified by [XQuery 1.0], generating a tuple stream. Then the satisfies clause is evaluated once for each tuple in the tuple stream, in order. If the satisfies clause contains a sequential expression, the side effects of each iteration are visible to subsequent evaluations of the return clause.

Additional Semantics:

The pending update list returned by the quantified expression is calculated by merging the pending update lists from the quantified expression clauses and the satisfies expression using upd:mergeUpdates.

6.10 Typeswitch Expressions

Category Rules:

The operand, case and default expressions can be of any type. An error [err:SXST0002] is raised if one of the expressions is updating and another is sequential.

• If an operand, case or default expression is an updating expression, the typeswitch expression is an updating expression.

• If an operand, case or default expression is a sequential expression, the typeswitch expression is a sequential expression.

• Otherise, the typeswitch expression is a simple expression.

Evaluation Order:

The operand expression is evaluated first. Then, exactly one of the return expressions is evaluated.

Additional Semantics:

The pending update list returned by the typeswitch expression is calculated by merging the pending update lists from the operand expression and the executed branch of the typeswitch expression using upd:mergeUpdates.

6.11 Insert, Delete, Replace, and Rename Expressions

Category Rules:

Insert, delete, replace, and rename expressions are updating expressions, and are extended to accept both updating and simple expressions as their operands. It is a static error [err:SXST0002] for the operand of one of these expressions to be a sequential expression.

Evaluation Order:

Order of evaluation for insert, delete, replace, and rename expressions is irrelevent since their operands cannot be sequential expressions.

Additional Semantics:

The pending update list returned by insert, delete, replace, and rename expressions is calculated by merging the pending update lists from the operands of the expression and the pending update list produced by the expression itself using upd:mergeUpdates.

6.12 Transform Expressions

Category Rules:

The copy, modify and return clauses of a transform expression can be of any type. An error [err:SXST0002] is raised if one of the copy or return clauses is updating and either the copy, modify or return clauses is sequential.

• If one of the copy or return clauses is an updating expression, the transform expression is an updating expression.

• If one of the copy, modify or return clauses is a sequential expression, the transform expression is a sequential expression.

• Otherise, the transform expression is a simple expression.

Evaluation Order:

Copy clauses are evaluated in order, then the modify expression is evaluated. Finally the return clause is evaluated.

Additional Semantics:

The semantics of a transform expression as defined in Section 2.4.5 Transform^XU are extended as follows:

• If the modify clause returns a non-empty XDM instance it is discarded.

• The pending update list returned by the transform expression is calculated by merging the pending update lists from the copy clause and the return clause using upd:mergeUpdates.

6.13 Other Expressions

All expressions not listed above are extended as follows. This includes the following kinds of expressions:

• Range expressions

• Union, intersect, and except expressions

• Arithmetic, comparison, and logical expressions

• Ordered and unordered expressions

• Instance of, cast, castable, and treat expressions

• Validate expressions

• Extension expressions (pragmas)

Category Rules:

All other expressions are extended to accept any type of expressions as their operands. An error [err:SXST0002] is raised if one of the operands is updating and another is sequential. If an operand of the expression is updating then the expression itself is updating, if an operand is sequential then the expression itself is sequential, otherwise it is simple.

Evaluation Order:

Operand expressions are evaluated once, from left to right.

Additional Semantics:

The pending update list returned by any other expression is calculated by merging the pending update lists from the operands of that expression using upd:mergeUpdates.