5722 2008-05-29 09:39:44 +0000 [XQuery] Importing the same module from different modules. 2009-02-24 17:05:06 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 1.0 Candidate Recommendation PC Windows NT RESOLVED REMIND P2 normal --- 1 oliver jonathan.robie jim.melton public-qt-comments oldest_to_newest 20303 0 oliver 2008-05-29 09:39:44 +0000 Assume a module M declaring a variable $v as <a/>. Then assume modules A and B both importing M, and exposing functions f() returning $v. Finally assume a query importing modules A and B. Should "A:f() is B:f()" evaluate to true? As far as I can tell this is implementation defined, since the import statement itself imports an implementation-defined set of modules (and so it is implementation defined whether it imports the same module as before, or a copy). On the other hand the specification states that "Each module has its own static context", but this still doesn't say whether the two imports should be considered as the same module. 20306 1 oliver 2008-05-29 13:23:48 +0000 Consider now a module M' with the same namespace as M that also declares a variable $v. (but neither M nor M' import their own namespace) Now assume A imports M (referring to it specifically via a location hint) and B imports M'. The behaviour of a query importing A and B is implementation defined. I can see several different things to do here: 1) Import both M and M' in both A and B. In this case an error is reported because the same variable is declared in both M and M'. However the drawback with this approach is that a library can be written using variables and functions in one module, whilst importing a different module in the same namespace. When it is imported by a different query it may cease to function. 2) Import M and M' as different libraries (albeit with the same namespace) into A and B respectively. This does allow there to be two global variables with the same name and namespace, although at no point are both in scope. 3) Ignore one of the location hints. This could lead to unexpected and arbitrary behavior. 4) Treat M and M' as different libraries (that is do not allow A to have access to M', and vice versa), but raise an error if there are any variable/function collisions (but do allow both M and M' to both import another module in the same namespace) What are other implementations doing in this case? The specification could go further by specifying the following: 1) Whether the "implementation-defined set of modules that share this target namespace" is always the same set of modules for the same namespace (excluding the module doing the importing). 2) If this is not true, then whether the union of all these sets of modules can contain two variables/functions with the same name. 20369 2 jmdyck 2008-06-03 19:28:45 +0000 [personal response:] I don't think the spec supports the notion of "importing a *copy* of a module". So, in the first scenario, where there's only one module implementing the imported namespace, A and B do import the same module, and "A:f() is B:f()" evaluates to true. In the second scenario, if the user attempts to have A import M and B import M', then I believe each of (1), (2), and (4) is a justifiable outcome. Re (3), the implementation is certainly free to ignore location hints, but it's still obliged to define which set of modules is imported in each case, which would then result in an outcome such as (1), (2), or (4) (or others). I think (2) vs (4) hinges on an ambiguity in the spec. For example, 4.11 says: It is a static error if the expanded QName of a variable declared in an imported module is equal ... to the expanded QName of a variable declared in the importing module or in another imported module ... Where it says "another import module", does it mean another module imported by the importing module or another module imported anywhere in the universe of the query ? The former interpretation allows outcome (2) but not (4); the latter allows (4) but not (2). Anyhow, I agree that the spec is fairly vague on the matter. 23906 3 jonathan.robie 2009-02-24 17:05:06 +0000 We agreed to adopt http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2009Feb/0041.html as a normative appendix.