[Bug 8873] Scope of static context components is inconsistently defined

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


Michael Dyck <jmdyck@ibiblio.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdyck@ibiblio.org




--- Comment #2 from Michael Dyck <jmdyck@ibiblio.org>  2010-02-03 21:35:26 ---
(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.


-- 
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 Wednesday, 3 February 2010 21:35:27 UTC