W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2012

[Bug 15728] New: Scope of variables defined in group-by

From: <bugzilla@jessica.w3.org>
Date: Thu, 26 Jan 2012 08:59:22 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-15728-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15728

           Summary: Scope of variables defined in group-by
           Product: XPath / XQuery / XSLT
           Version: Member-only Editors Drafts
          Platform: PC
        OS/Version: All
            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


The scope of variables declared in a group-by clause is governed by the general
rules in 3.10.1:

The scope of a bound variable includes all subexpressions of the containing
FLWOR that appear after the variable binding.

(This differs from the window clause, which has rules of its own).

This means that it is legal to write:

for $e in //employee
group by $s := $e/salary, $t := string($s)

But we don't say what this is supposed to mean. We say in 3.10.7:

For each pre-grouping tuple, the grouping keys are computed by evaluating the
expression in the GroupingSpec and atomizing the result.

But $s is not present in the pre-grouping tuple, and therefore $t cannot be
computed for a pre-grouping tuple. And we can't use the value of $s from the
post-grouping tuple because that's only available after doing the grouping, and
we can't do the grouping until we know $t. We could try to define some kind of
model where the grouping is done in a sequence of steps each of which generates
intermediate tuples, but it would be complex and probably lead to more
surprises. Or we could try to do a syntactic transformation of the above to

for $e in //employee
let $s := $e/salary
let $t := string($s)
group by $s := $s, $t := $t

(which is the reverse of the current transformation)

As I can't see any practical uses that require this kind of construct, I think
the simplest solution is to modify the scope rules so that in a group by
clause, the variables declared within the clause are not in scope within that
clause. We already have custom scope rules for the window clause, it's not a
big deal to also introduce custom rules for the group by clause.

-- 
Configure bugmail: https://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 Thursday, 26 January 2012 08:59:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:47 UTC