This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Some quibbles about in-scope variables. 2.1.1, under in-scope variables, says "An expression that binds a variable (such as a let, for, some, or every expression) extends the in-scope variables of its subexpressions with the new bound variable and its type." This is almost fine for XPath, but not for XQuery, where there is no such thing as a "let" or "for" expression; even in XPath, it's not strictly true, since in "for $x in A return B", A is a subexpression of the for-expression, but $x is not in scope for A. Perhaps remove "of its subexpressions" and add a statement that the detailed rules are to be found in the description of each variable-binding expression. Section 3.9.1 has a more detailed explanation: it states "The scope of a bound variable includes all subexpressions of the containing FLWOR that appear after the variable binding. The scope does not include the expression to which the variable is bound." Section 3.9.4 (windowing) has a further statement: "The scoping rules for the variables bound by a window clause are as follows:..." I think this statement is equivalent to the one in 3.9.1, but it requires very careful reading to determine this. If the statements are indeed equivalent, it would be nice to remove the redundancy. A consequence of this rule is that an expression in a window clause is allowed to reference a variable which is not present in its input tuple stream (or in the outer context of the FLWOR expression). So the statement in the introduction to 3.9 "Conceptually, the initial clause generates a tuple stream. Each intermediate clause takes the tuple stream generated by the previous clause as input and generates a (possibly different) tuple stream as output. " is a little misleading: it doesn't suggest the possibility that evaluating a clause might require access to variables bound within that clause.
In fact closer examination reveals that the statement in 3.9.4 is not equivalent to that in 3.9.1, because the "window" variable is not available for use anywhere within the window clause itself, only in subsequent clauses. So the statement in 3.9.1 is not completely general.
(In reply to comment #0) > Some quibbles about in-scope variables. > > 2.1.1, under in-scope variables, says "An expression that binds a variable > (such as a let, for, some, or every expression) extends the in-scope variables > of its subexpressions with the new bound variable and its type." Changing to: "An expression that binds a variable extends the in-scope variables, within the scope of the variable, with the variable and its type." The individual expressions define the scope of the variables they bind, we shouldn't do that here. > Section 3.9.1 has a more detailed explanation: it states "The scope of a bound > variable includes all subexpressions of the containing FLWOR that appear after > the variable binding. The scope does not include the expression to which the > variable is bound." > > Section 3.9.4 (windowing) has a further statement: "The scoping rules for the > variables bound by a window clause are as follows:..." I think this statement > is equivalent to the one in 3.9.1, but it requires very careful reading to > determine this. If the statements are indeed equivalent, it would be nice to > remove the redundancy. These aren't quite equivalent; the problem is that 3.9.1. implies they are. I'm fixing this. > A consequence of this rule is that an expression in a window clause is allowed > to reference a variable which is not present in its input tuple stream (or in > the outer context of the FLWOR expression). So the statement in the > introduction to 3.9 "Conceptually, the initial clause generates a tuple stream. > Each intermediate clause takes the tuple stream generated by the previous > clause as input and generates a (possibly different) tuple stream as output. " > is a little misleading: it doesn't suggest the possibility that evaluating a > clause might require access to variables bound within that clause. Here I don't think there's a real problem. "Conceptually" is a signal that this is a high level statement, there's a detail that isn't mentioned here, but which is mentioned later. I'm leaving this as is. (In reply to comment #1) > In fact closer examination reveals that the statement in 3.9.4 is not > equivalent to that in 3.9.1, because the "window" variable is not available for > use anywhere within the window clause itself, only in subsequent clauses. So > the statement in 3.9.1 is not completely general. Here, I think the main problem is the 3.9.1 claims to cover the window clause as well, when it does not. I'm fixing this by removing "window" from this list: <quote> The following clauses in FLWOR expressions bind values to variables: for, let, window, and count (in addition, a group by clause changes the values of variables that were previously bound.) In each case, binding of variables is governed by the following rules:</quote> and adding a forward reference: The binding of variables for <code>for</code>, <code>let</code>, and <code>count</code> is governed by the following rules (the binding of variables in <code>window</code> clauses is similar; see <specref ref="id-windows"/>):