The simplest fix may be to define the scope of components in terms of the static context of the expressions found in a given scope.


http://www.w3.org/TR/xquery-11/#id-xq-static-context-components

Existing text:

> Scope: Indicates where the component is applicable. "Global"
> indicates that the component applies globally, throughout all the
> modules used in a query. "Module" indicates that the component
> applies throughout a module. "Lexical" indicates that the component
> applies within the expression in which it is defined (equivalent to
> "module" if the component is declared in a Prolog.)

Here's what it looks like if we define this in terms of the expressions found in a given scope:

If the scope is "Global", then every expression in the query shares
the component. If the scope is "Module", then every expression in the
module shares the component. If the scope is "Lexical", then the
component is associated with the expression in which it is defined.

(In reply to comment #0)
> XQuery defines the static context of an expression, but not the static
> context of a module or a query
> 
> However, the individual components that make up the static context of an
> expression can have module scope, global scope, or lexical scope
> 
> This inconsistency ...

I don't think that's an inconsistency. (The reason we can disagree on this is that "scope" isn't rigorously defined.)

> function signatures, which have module scope according to the table,
> ... are nevertheless defined in terms of the static context of a single
> expression:

That's fine with me. Function signatures are certainly part of the information that's available during static analysis of an expression (e.g., you use them to determine whether an expression raises XPST0017), so they definitely belong in the static context of an expression.

Scope (in the Appendix C.1 sense), on the other hand, says something about the relationship between the static contexts of different expressions.  For example, saying that the 'function signatures' component has "module scope", I take that to mean that if you look at the static context of every expression in a module, they'll all have the same setting for the 'function signatures' component.

That is, given the Appendix C.1 wording:
    "Module" indicates that the component applies throughout a module.
I interpret "applies" as meaning something like:
    "has the same setting in the static contexts of all the expressions"
(I don't know if the original intent was that detailed, I suspect not.)

Under this interpretation, C.1's 'Scope' column is, for the most part, a recap/rewording of information in the 'overwritten/augmented' column:

   if the component can be overwritten by an expression,
       scope is "lexical",
   else if it can be overwritten by (something in) the prolog,
       scope is "module",
   else (it can't be overwritten),
       scope is either "module" or "global".

(The entry for "context item static type" is currently an exception to this rule, but that's because of a bug in its "overwritten" cell that I've logged as Bug 8875.)

(It's interesting that some non-overwriteable components "module" scope and some have "global" scope. E.g., 'statically known collations' and 'statically known documents' have "module" scope, which seems to allow them to vary from module to module. Is this intended? Is it beneficial?)

   
> Because function signatures have module scope, it seems odd that they are
> defined at the expression level.

Not to me. Function signatures are necessary for static analysis at the expression level, so they must be "available" at the expression level. (Personally, I wouldn't say they're "defined" at the expression level, because that's more prone to misinterpretation.)


> And the definition of module import actually refers to the function signatures
> of a module - even though that is not defined in our specification:

Yes, *that* is definitely an inconsistency. In fact, it's even more blatant in section 4.12 [Module Import], 5th paragraph:

    "Each module has its own static context."

    http://www.w3.org/TR/xquery-11/#id-module-import

> I believe this is an editorial issue, not a substantive one.

I pretty much agree on that, although it's possible that sorting it out might uncover some substantive issues.

I believe this is now fixed in the internal working draft:

http://www.w3.org/XML/Group/qtspecs/specifications/xquery-11/html/xquery-11.html#id-xq-context-components

[Definition: The scope of a component is the context in which the component is associated with a value.] The following scopes are defined:

* [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.]

* [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.]

* [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.]

* [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.]

The concept of "global" scope seems a bit unnecessary: the only component defined with global scope is XPath 1.0 compatibility mode, which has a fixed value of "false", and it could therefore have that fixed value at module scope without any detrimental effects. In fact, we really don't want anything in the static context to have global scope, since it will invariably get in the way of separate compilation of modules. So I would recommend getting rid of it.

(In reply to comment #4)
> The concept of "global" scope seems a bit unnecessary: the only component
> defined with global scope is XPath 1.0 compatibility mode, which has a fixed
> value of "false", and it could therefore have that fixed value at module scope
> without any detrimental effects. In fact, we really don't want anything in the
> static context to have global scope, since it will invariably get in the way of
> separate compilation of modules. So I would recommend getting rid of it.


Lexical scope and dynamic scope actually have the same scope, in each case the scope is determined by the expression that defines it.  

The difference is whether the value can be changed at run-time - but that's not really a scope question, is it?

We might be able to cut the number of scopes down to 2, rather than 4.