Let and For clause
Let and for clauses enable the binding of variables to results of any XQuery expressions, whereby, as shown in the further course, the results of path expressions are normally bound to variables in let and for clauses. Each variable which is bound in a let or for clause is known from this moment and (de-)referenceable in all following constructs. The semantics of the two clauses differs as follows:
- let clause: The result of the expression is completely bound as sequence of nodes and/or values to the variable.
- for clause: The result of the expression is bound element wise to the variable and the following query construct is individually executed for each element.
The different semantics becomes already apparent in the grammar. On the one hand, let clauses bind the entire result of an expression with := to the respective variable and on the other hand, for for clauses the grammar requires the use of the in key word.
It should be noted here that within a XQuery instruction – in contrast to classical concepts of programming languages – a variable identifier must not be used multiple times on the left side, which means in the scope of a value assignment.
The different semantics of let and for clauses is demonstrated as an example by the following FLWOR expression where occupational groups shall be listed. A let clause binds the list with the three items to the $x variable and activates once the return operator for the generation of the result document.
let $x := (<Doctor/>, <Nurse/>, <Technician/>)
return
<OccupationalGroups>{ $x }</OccupationalGroups>
This FLWOR expression returns the following result:
<OccupationalGroups>
<Doctor/><Nurse/><Technician/>
</OccupationalGroups>
In contrast, a for clause (for $x in (...)) would effect, instaed of the let clause, that the return operator is called up for each allocation of the $x variables, so that the following result would be constructed:
<OccupationalGroups><Doctor/></OccupationalGroups>
<OccupationalGroups><Nurse/></OccupationalGroups>
<OccupationalGroups><Technician/></OccupationalGroups>
Nevertheless, in order to get the same result as above, the element constructor would have to be pulled outwards for the root of the result document and with this the FLWOR expression would have to be inserted into the element construction:
<OccupationalGroups>
{
for $x in (<Doctor/>, <Nurse/>, <Technician/>)
return $x
}
</OccupationalGroups>
With the usage of the computed element constructor this would lead to the following equivalent query formulation:
element OccupationalGroups
{
for $x in (<Doctor/>, <Nurse/>, <Technician/>)
return $x
}
Evaluation context
Here it is necessary to note the opening of a new evaluation context. The above FLWOR expression must occur in a new evaluation context, because the query processor is in the static mode after the start of the <OccupationalGroups> element and the missing of the {} bracket would not initiate an evaluation of the FLWOR expression, but only a textual output. The same applies within a return clause. If, without additional XML tags, a variable is dereferenced, the processor is still in the evaluation mode. However, once a variable, as in the above let example, within a tag occurs in a return clause, this clause must be dereferenced within a new evaluation context.
Source: "XQuery – Grundlagen und fortgeschrittene Methoden", dpunkt-Verlag, Heidelberg (2004)
<< back | next >> |