This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10368 - [XQuery30] review of appendix C re scope of components
Summary: [XQuery30] review of appendix C re scope of components
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.0 (show other bugs)
Version: Member-only Editors Drafts
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-14 18:48 UTC by Michael Dyck
Modified: 2011-11-15 21:14 UTC (History)
2 users (show)

See Also:


Attachments

Description Michael Dyck 2010-08-14 18:48:49 UTC
(This comment is basically my message
http://lists.w3.org/Archives/Member/w3c-xsl-query/2010May/0041.html
from 2010-05-03.)

Here are my comments, all editorial...

> [Definition: The *scope* of a component is the context in which
> the  component is associated with a value.]

(1)
Is this using "context" in the sense of "static or dynamic context"? If 
so, it doesn't make much sense. For the most part, any given component is 
associated with a value in *every* static/dynamic context, so talking 
about *the* context in which this occurs is probably a mistake.

Or, if you mean "context" in some other sense, that's probably not a good 
idea, since Appendix C is almost entirely about static and dynamic contexts.


> [Definition: If a component has *global scope*, then every expression
> in the query has the same value for that component, and it can not be
> overwritten by the query module or by an expression.]

(2)
The phrase "every expression ... has the same value" is a garden path: it 
   may mislead the reader into thinking that you're talking about the 
value of an expression. I suggest that, throughout this appendix, instead 
of talking about the *value* of a component, we use some other word, e.g. 
"setting". (This is appropriate, because a component's setting is in 
general not an XDM value.) And/or we could alter the syntax somewhat, e.g.:
     ... then the [value/setting] of that component is the same
     for every expression in the query ...

(3)
The "and" in "and it can not be overwritten by the query module or by an 
expression" suggests that this clause is saying something new, but in 
fact it's a logical consequence of the preceding clause.

(4)
The phrase "query module" is undefined. I think it's (currently) used to 
mean "module", but I think readers might take it to mean "main module" 
(because that's the module that "contains the query"). I think we should 
avoid it. Instead, just say:
     "by any module or expression"

(5)
(Speaking of "query module", it looks like the thread I started at
http://lists.w3.org/Archives/Member/w3c-xsl-query/2010Feb/0007.html
never really got resolved.)

(6)
(There's also an occurrence of "query module" in 4.12.3 that should just 
be "module".)


> [Definition: If a component has module scope, then every expression
> in a given module has the same value for that component, and it can be
> overwritten or augmented for a given module.]

(7)
Instead of talking about overwriting or augmenting, maybe say something like:
     "but that value [setting] may differ between modules"


> [Definition: If a component has lexical scope, then it is defined by
> a query expression, and its scope is defined by the semantics of the
> expression that defines it.]

(8)
You're saying that a component is *defined by* an expression. I'm 
inclined to say that context components are defined by section 2.1 
[Expression Context].

(9)
The phrase "defined by a query expression" prompts the question "Which 
query expression?", which I don't think is what's wanted. Maybe
     "set by certain kinds of expression"
would be better. (It prompts the question "Which kinds?", which has a 
good answer, although we don't currently give it.)

(10)
By the way, I suggest changing "query expression" to just "expression".

(11)
It's odd for the definition of "lexical scope" to say that "its scope is 
defined by [something else]". That's getting into another (more 
conventional) meaning of "scope", which I think muddies the waters.

(12)
This definition diverges from the pattern set up by the previous 
definitions. A more consistent one would be something like:
     [Definition: If a component has lexical scope, then the setting
     of that component is fixed for any given expression, but may differ
     between expressions in the same module.]


> [Definition: If a component has dynamic scope, then it is defined by a
> query expression, its scope is defined by the semantics of the expression
> that defines it, and run-time evaluation may influence its value.]

(8, 9, 10, 11 again)
As above re "defined by a query expression" and "its scope is defined".

(13)
We should probably delete "run-time", as its presence might suggest an 
distinction from compile-time evaluation, which we don't intend.

(14)
A more consistent definition would be something like:
     [Definition: If a component has dynamic scope, then the setting of
     that component may differ between the contexts of a single
     expression.]

----

(15)
As I said here:
http://lists.w3.org/Archives/Member/w3c-xsl-query/2010Mar/0189.html
I think we should replace occurrences of "scope" in Appendix C with a 
different word. There I suggested "range" or "ambit". Now, I think I'd 
prefer something like "constancy" or "changeability". E.g.:
     [Definition: The *constancy* of a component indicates (roughly)
     the set of [static or dynamic] contexts in which that component
     has a common setting, or conversely, the level of granularity at
     which the setting of that component may differ between contexts.]

----

(16)
(Note that all of the above is independent of the other issue that it got 
tangled up with, namely that the spec is inconsistent on whether a module 
has a static context. I bring it up just so it doesn't get forgotten.)
Comment 1 Michael Kay 2010-08-14 20:14:27 UTC
I basically agree with the originator that the current text is a mess. However, it would be more constructive to propose a rewording of the entire section (it's not an easy task).
Comment 2 Michael Dyck 2010-08-14 20:34:36 UTC
(In reply to comment #1)
> it would be more constructive to propose a rewording of the entire section

Including or excluding subsections?
Comment 3 Michael Dyck 2011-10-04 05:09:21 UTC
Here is my proposal to resolve this issue:

(A)
Remove all use of appendix C's specialized meaning for 'scope'.

Specifically, remove:
 -- In C, the definition of "scope of a component" + its bullets.
 -- In C.1, the "Scope" bullet and column.
 -- In C.2, the "Scope" bullet and column.
 -- In H, the definitions for:
     -- dynamic scope,
     -- global scope,
     -- lexical scope,
     -- module scope, and
     -- scope of a component.

Outside of appendix C, the only other potential use of that meaning of
"scope" is in 2.1.1 Static Context:
    "Rules governing the scope and initialization of these components
    can be found in C.1 Static Context Components."
We could delete "the scope and", or we could just leave it and let it be
interpreted in a traditional sense.

(Note that, in C.1, the consistency rules for
 -- Statically known namespaces
 -- Default element/type namespace
 -- In-scope variables
are of roughly the form:
    "Only one X per Y per lexical scope"
These are using "scope" in a more traditional sense.  So:
 -- They could just stay as is. OR
 -- The "per lexical scope" could be deleted, since it roughly means
    "in a given static context", which is clearly implied for all
    consistency rules in C.1. OR
 -- The entire consistency rule could be removed, since it's implied
    by the "data type" of the component. (E.g., 'Statically known
    namespaces' and 'In-scope variables' are defined as mappings, which
    implies only one "value" per "key".)
)

This removal is without normative repercussions, because (as I pointed
out in Bug 8873 comment #2) the content of the "scope" column is
redundant, given the content of the "overwritten/augmented by query"
column:

    For components of the static context:
       if it can be overwritten by an expression,
           scope is "lexical",
       else
           scope is "module".

    For components of the dynamic context:
        if it can be overwritten/augmented by an expression,
            scope is "dynamic",
        else
            scope is "global".

The only exception to the above rule is 'XPath 1.0 Compatibility Mode',
for which the above rule would predict "module", but which is actually
labelled "global".  However, its consistency rule ("Must be false")
renders the distinction uninformative.

(B)
Now, you might say "Okay, it's redundant, but it's still a helpful
summary of the preceding column". My response is:
 -- Its helpfulness is not worth the churn it has caused, and
 -- You could probably achieve a similar effect by:
    (1) Splitting the preceding column into two:
        "Can be overwritten or augmented by prolog?"
        and
        "Can be overwritten or augmented by expressions?"
    (2) Grouping the overwritten-by-expression components together.

--------------

The change in (A) addresses all of the points in comment 1 except
(5), (6), and (16).

Re (5) and (6), see Bug 14374.

Re (16), see Bug 14375.
Comment 4 Michael Dyck 2011-11-07 19:06:19 UTC
Meeting #490 of the XQuery WG approved the proposal in comment #3.
Comment 5 Michael Dyck 2011-11-15 21:14:55 UTC
The editor's draft of the XQuery document now reflects the proposal in comment #3.