[Bug 13702] [XQuery 3.0] Scope of variables in FLWOR expressions

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13702

Jonathan Robie <jonathan.robie@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Jonathan Robie <jonathan.robie@gmail.com> 2011-09-10 17:15:39 UTC ---
(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"/>):

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 10 September 2011 17:15:46 UTC