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

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

           Summary: [XQuery 3.0] Scope of variables in FLWOR expressions
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 3.0
        AssignedTo: jonathan.robie@gmail.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


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.

-- 
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 Sunday, 7 August 2011 15:16:28 UTC