10368 2010-08-14 18:48:49 +0000 [XQuery30] review of appendix C re scope of components 2011-11-15 21:14:55 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3.0 Member-only Editors Drafts All All RESOLVED FIXED P2 minor --- 1 jmdyck jonathan.robie jim.melton mike oldest_to_newest 37419 0 jmdyck 2010-08-14 18:48:49 +0000 (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.) 37420 1 mike 2010-08-14 20:14:27 +0000 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). 37421 2 jmdyck 2010-08-14 20:34:36 +0000 (In reply to comment #1) > it would be more constructive to propose a rewording of the entire section Including or excluding subsections? 57754 3 jmdyck 2011-10-04 05:09:21 +0000 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. 59695 4 jmdyck 2011-11-07 19:06:19 +0000 Meeting #490 of the XQuery WG approved the proposal in comment #3. 60059 5 jmdyck 2011-11-15 21:14:55 +0000 The editor's draft of the XQuery document now reflects the proposal in comment #3.