This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
[Note that this issue could be filed against XQuery 1.0 or 3.0, or against their respective test suites. Not sure which is best.] Consider the query: main module: import module "NEAR"; declare namespace far = "FAR"; declare variable $far:v := "foo"; $far:v library module: module namespace near = "NEAR"; import module "FAR"; library module: module namespace far = "FAR"; declare variable $far:v := 42; declare variable $far:x := $far:v; Note that the global variable name $"FAR":v is declared in two places with two different values. I know of at least one XQuery implementation that claims this is a static error (XQST0049), but I believe doing so is non-conformant, because the two declarations do not "come into contact": there isn't a module that declares/imports both. If it doesn't raise an error, then it would be good to add this example to the test suite(s). If it does raise an error, then please point out the rules that cause this. [This is an elaboration of the example in (member-only) http://lists.w3.org/Archives/Member/w3c-xsl-query/2011Oct/0015.html]
(In reply to comment #0) > Consider the query: > main module: > import module "NEAR"; > declare namespace far = "FAR"; > declare variable $far:v := "foo"; > $far:v The above import brings in the names in module NEAR, but not those in module FAR. Import is not transitive. > library module: > module namespace near = "NEAR"; > import module "FAR"; No variables here to clash. > library module: > module namespace far = "FAR"; > declare variable $far:v := 42; > declare variable $far:x := $far:v; $far:x in this module shouldn't be imported. > Note that the global variable name $"FAR":v is declared in two places with two > different values. I know of at least one XQuery implementation that claims this > is a static error (XQST0049), but I believe doing so is non-conformant, because > the two declarations do not "come into contact": there isn't a module that > declares/imports both. I agree. And I know at least one other XQuery processor has the same problem. > If it doesn't raise an error, then it would be good to add this example to the > test suite(s). > > If it does raise an error, then please point out the rules that cause this. I don't think the spec says it raises an error. Allowing an error here would be backwards incompatible, at least with the spec. I'm wondering how many implementations get this one right.
This is partly covered by the non-normative J.2 in XQuery 1.0: "it is suggested that in such cases implementations should require the names of global variables and functions to be unique within the query as a whole: that is, if two modules with the same module URI participate in a query, the names of their global variables and functions should not overlap." We added this in the second edition and made it non-normative because we didn't want to invalidate existing implementations. However, we have made the text normative in XQuery 3.0 (see 4.12.2), as we reasoned that interoperability across implementations in this area is more important than backwards compatibility. I think the statement "The names of public global variables and public functions must be unique within the query as a whole" justifies a processor in rejecting the example given, even though it's not covered by the elaboration that follows: ("that is, if two modules with the same module URI are used in the same query, the names of their global variables and functions must not overlap")
(In reply to comment #2) Hmmm, you're right, and this is particularly clear in the XQuery 3.0 text. 4.12.2 Multiple Modules with the same Module URI Several different modules with the same Module URI can be used in the same query. The names of public global variables and public functions must be unique within the query as a whole: that is, if two modules with the same module URI are used in the same query, the names of their global variables and functions must not overlap. If one module contains an "import module" declaration for the module URI M, then all public global variables and public functions declared in participating modules whose module URI is M must be accessible in the importing module, regardless whether the participation of the imported module was directly due to this "import module" declaration.
But, as Michael Kay points out, the "that is, ..." elaboration doesn't cover this example. (Plus, it only says "should not".) Similarly, the section title ("Multiple Modules with the same Module URI") doesn't apply to this example. Moreover, the "must be unique" statement doesn't supply an error code for cases where it's violated. So, while I agree that a processor has some justification for rejecting the example, I think it would also be justified in allowing the example. Presumably we should do some editing so that it's clearly one or the other. (I don't much care which.) Or would we leave it up to the implementation?
(In reply to comment #4) > Presumably we should do some editing so that it's clearly one or the other. (I > don't much care which.) Or would we leave it up to the implementation? I would hate to leave it up to the implementation. I believe the original XQuery 1.0 behavior was changed in the 2d edition, as Mike Kay points out, this may be a matter of older text that still reflects the original behavior. I find this behavior a bit weird: even though the name of the variable is not imported into the main module, the names clash. I would expect name clashes to occur only both names are available in the same context. (In reply to comment #4) > But, as Michael Kay points out, the "that is, ..." elaboration doesn't cover > this example. (Plus, it only says "should not".) In XQuery 2ed, it did say "should not", because of concern with backwards compatibility. Later, we decided to make this normative. > Similarly, the section title ("Multiple Modules with the same Module URI") > doesn't apply to this example. True ... > Moreover, the "must be unique" statement doesn't supply an error code for cases > where it's violated. And that's definitely missing. > So, while I agree that a processor has some justification for rejecting the > example, I think it would also be justified in allowing the example. > > Presumably we should do some editing so that it's clearly one or the other. (I > don't much care which.) Or would we leave it up to the implementation? I would hate to leave it up to the implementation. My personal preference would be to say that name clashes can only occur if both names are available in the same context. Just as private variables do not result in name clashes, a module import only results in name clashes for names that it actually imports. It seems strange to raise an error for a name that is not imported.
There are other complications to take into account such as external variables, whose names are visible externally. It would greatly complicate an API if it had to cope with multiple external variables having the same name.
(In reply to comment #6) > There are other complications to take into account such as external variables, > whose names are visible externally. It would greatly complicate an API if it > had to cope with multiple external variables having the same name. That's a good point.
(In reply to comment #6) > It would greatly complicate an API if it had to cope with > multiple external variables having the same name. If an implementation allowed a query to have two (not in contact) modules with external variable declaration with the same variable name, then I think the implementation would be permitted to treat them as referring to the same external entity, and so not complicate the API. ("The means by which typed values of external variables are provided by the external environment is implementation-defined", so an implementation can assert that it will provide the same value to the two variables.) (If the declarations have conflicting types, I think the implementation would be allowed to raise a type error, during static analysis or dynamic evaluation.)
Thinking more about the API issue. Suppose a module has private external variables. The API would need a way to assign those by name. Each module might have a private external variable with the same name. That means you have to identify both the module and the variable name. If you have that solution in place, I don't think that the resolution of this issue affects the complexity of the API one way or another.
The Working Group endorses the understanding in Comment #1. No change is required in the specification. We need test cases for this.
In further discussion, we have determined we are unable to reach consensus for XQuery 3.0. XQuery 1.0 licensed both behaviors, and implementations have implemented both. We do not have a model or wording to define a global dynamic context. Note that users can make use of private variables to ensure interoperability.
(In reply to comment #11) > In further discussion, we have determined we are unable to reach consensus for XQuery 3.0. Presumably that means that the status quo stands: 4.12.2: "The names of public global variables and public functions must be unique within the query as a whole".
(In reply to comment #12) > > Presumably that means that the status quo stands: > > 4.12.2: "The names of public global variables and public functions must be > unique within the query as a whole". There was no decision to change that text, so it does stand. Whether it should be described as "the status quo" is perhaps debatable. There was certainly a lack of consensus that it could be taken as the spec's definitive answer to the original question. I believe there was general agreement that, on this point, the spec is unclear, and should be made clearer, but we're not sure how, and we're not doing anything about it right now.