This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
[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.
We agreed to adopt http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2009Feb/0041.html as a normative appendix.