W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2006

[Bug 3192] [FS] editorial: 5.11 Module Import

From: <bugzilla@wiggum.w3.org>
Date: Thu, 04 May 2006 04:50:15 +0000
To: public-qt-comments@w3.org
Message-Id: <E1FbVn5-0006Zm-N5@wiggum.w3.org>


           Summary: [FS] editorial: 5.11 Module Import
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Formal Semantics
        AssignedTo: simeon@us.ibm.com
        ReportedBy: jmdyck@ibiblio.org
         QAContact: public-qt-comments@w3.org

5.11 Module Import

Notation 4 / rule 2
fs:local-variables(statEnv2, URILiteral)
fs:local-functions(statEnv2, URILiteral)
    I think there's a missing connection between dynEnv2 in the conclusion
    and statEnv2 in the premises.

SCP / rule (1|2)
URILiteral1 =>module_statEnv statEnv1
URILiteral1 =>module_statEnv statEnvn
    The prose says that these premises look up the static contexts of
    all the imported modules. However, this doesn't really work...

    1) There's no guarantee that it hits all importable modules. (E.g.,
       the inference process can pick n=1 and satisfy the rule with just
       one module, regardless of the number that could have satisfied it.)

    2) Even if we assume that the inference process somehow knows the
       "right" value for n, there's still no guarantee that it will bind
       the statEnvs to n distinct environments (from n different modules),
       since there's no requirement that the statEnvi be distinct.

    In either case, the inference process can deduce the wrong statEnvn'.

    Instead, I repeat my suggestion (from Bug 1704) to introduce a
    function like fs:library-modules-with-target-namespace(N).

DCP / rule 1
Received on Thursday, 4 May 2006 04:50:40 UTC

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