This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 3192 - [FS] editorial: 5.11 Module Import
Summary: [FS] editorial: 5.11 Module Import
Status: ASSIGNED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Formal Semantics 1.0 (show other bugs)
Version: Candidate Recommendation
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Michael Dyck
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-04 04:50 UTC by Michael Dyck
Modified: 2007-11-04 06:00 UTC (History)
0 users

See Also:


Attachments

Description Michael Dyck 2006-05-04 04:50:15 UTC
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
    Similarly.
Comment 1 Jim Melton 2007-02-26 00:12:15 UTC
The fix for this bug does not appear in the Recommendation of 23 January 2007. 
It will be considered for a future publication (either an Errata document or
some possible future version of the specification). 
Comment 2 Michael Dyck 2007-03-06 03:41:17 UTC
It looks like the SCP comment has been overtaken by the resolution of Bug 1705.

The other comments stand, though.