- From: <bugzilla@wiggum.w3.org>
- Date: Thu, 04 May 2006 04:50:15 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3192
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
Similarly.
Received on Thursday, 4 May 2006 04:50:40 UTC