W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2010

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

From: <bugzilla@wiggum.w3.org>
Date: Wed, 03 Feb 2010 15:26:17 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-8873-523@http.www.w3.org/Bugs/Public/>

           Summary: Scope of static context components is inconsistently
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery
        AssignedTo: jonathan.robie@redhat.com
        ReportedBy: jonathan.robie@redhat.com
         QAContact: public-qt-comments@w3.org

XQuery defines the static context of an expression, but not the static context
of a module or a query:


> [Definition: The static context of an expression is the information
> that is available during static analysis of the expression, prior to
> its evaluation.] This information can be used to decide whether the
> expression contains a static error. If analysis of an expression
> relies on some component of the static context that has not been
> assigned a value, a static error is raised [err:XPST0001].

However, the individual components that make up the static context of an
expression can have module scope, global scope, or lexical scope:


> 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.)

This inconsistency affects the description of components such as function
signatures, which have module scope according to the table, but are
nevertheless defined in terms of the static context of a single expression:


> [Definition: Function signatures. This component defines the set of
> functions that are available to be called from within an
> expression. Each function is uniquely identified by its expanded
> QName and its arity (number of parameters).] In addition to the name
> and arity, each function signature specifies the static types of the
> function parameters and result.
> The function signatures include the signatures of constructor
> functions, which are discussed in 3.14.5 Constructor Functions.

Because function signatures have module scope, it seems odd that they are
defined at the expression level. And the definition of module import actually
refers to the function signatures of a module - even though that is not defined
in our specification:


> [Definition: A module import imports the variable declarations and
> public function declarations from one or more library modules into
> the function signatures and in-scope variables of the importing
> module.]

I believe this is an editorial issue, not a substantive one. Our descriptions
are inconsistent, but I think our intent is clear.

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 15:26:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:29 UTC