This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the Septemnber 15th draft there is a new paragraph in section 4.11 module import: A module may import its own target namespace (this is interpreted as importing all the other modules that share the same target namespace.) This is too strong, and conflicts with the implementation flexibility offered by this paragraph earlier in the same section: The first URILiteral in a module import specifies the target namespace of the modules to be imported. The URILiterals that follow the at keyword are optional location hints, and can be interpreted or disregarded in an implementation- defined way. Implementations are not required to import all modules for a namespace for different namespaces; they should not be so required just because the namespace happens to be the same. Proposal: strike "all the" and continue the parenthetical sentence "or by interpreting the location hints in an implementation-defined way"
(In reply to comment #0) > > Implementations are not required to import all modules for a namespace I think they are. I don't know about the Sept 15th draft, but the April 4th draft says (in the para before the one you quoted): "Each module import names a target namespace and imports all the modules that share this target namespace."
I agree (with Michael Dyck) - the spec says that when you import a namespace, you import all modules for that namespace, and this applies whether it's your own namespace or not. Of course, you can only import those modules that you know about, but my interpretation is that this includes any modules reached transitively. For example if A imports N at N1, and N1 imports N at N2, then I think A has access to the variables and functions declared in N2, regardless whether N is the namespace of A or not. Michael Kay
Yes, I now see this constraint added to modules in general and it appears to have snuck in in some earlier draft, where I missed it. Apologies for not having noticed this until now. I would, nevertheless, very much appreciate knowing when this new rule was agreed to. The last I remember significant discussions of module import semantics was at the August 2004 F2F (the whole module resources vs module renaming discussion). At that time, there was no such rule in the spec, and I see no such rule in the proposal we agreed to at that time. Indeed, I recall as part of the discussion (although this point doesn't seem to be captured in the official minutes) a rejection of this interpretation. This "all modules with that namespace" is a weird and unenforceable constraint anyway and should be dropped, especially if we never explicitly agreed to it.
I don't know the history of this, I'm afraid. The current rule for module import does have the advantage that it's reasonably analogous to the rules in XML Schema, where import is primarily about allowing reference to components in another namespace, rather than about locating the documents defining those components. (But I confess that XML Schema is far from being a wonderful role model in this area...). I think modules in their current state just about hang together. It's not a wonderful design but it more-or-less works. I don't think minor tweaks are going to improve it much.
I propose to resolve this issue by making the following changes: (1) In section 4.11, Module Import, change the second sentence of the first paragraph to the following: "Each module import names a target namespace and imports an implementation-defined set of modules that have this target namespace." (2)In section 4.11, fifth paragraph, change the first sentence to the following: "A module may import its own target namespace (this is interpreted as importing an implementation-defined set of other modules that share its target namespace.)" (3) Add the following item to the list of implementation-defined items in Appendix D: "The process by which the specific modules to be imported by a Module Import are identified." Regards, Don Chamberlin
Mary, On Sept. 28, 2005, the Query Working Group decided to adopt the text specified above (in Additional Comment #5). We believe that this action resolves the issue and addresses your concerns. I have marked this issue as "Fixed". If you are satisfied with the resolution, please respond by marking the issue as "Closed". Regards, Don Chamberlin
(In reply to comment #5) > > "Each module import names a target namespace and imports an > implementation-defined set of modules that have this target namespace." So if there are two or more modules co-operatively implementing a given target namespace, you can't portably know that they'll all be imported, so the only portable course of action is to never have more than one module for a given target namespace. Which raises the question, why does XQuery allow multi-module imports anyway? It seems to be a nasty complication with dubious benefit. Perhaps it should be deferred. Per Bothner suggested this 18 months ago and didn't get a good answer, in my opinion. http://lists.w3.org/Archives/Public/public-qt-comments/2004Mar/0013.html (I can see why you might want multiple *alternative* modules for a namespace, i.e., each one completely implementing a given interface, but that's a different matter. For that, you'd want assurance from the spec that exactly *one* of those modules would be imported.)
I'm satisfied with this resolution, although perhaps Michael Dyck is suggesting we reopen it (although it looks like a distinct issue to me). In answer to the question he poses (why allow more than one module per ns?) the short answer is because function namespaces and physical partitioning have nothing to do with one another. If your only choice is between putting all 20000 lines of XQuery into a single file or inventing random distinct namespaces just so you can partition the physical file (which will drive all the clients of that module completely spare trying to remember which function is in which namespace), you have no sane solution to a basic development issue. The current design also has the salutary effect of allowing one to hide all the "internal functions" in one physical file, have a "api library" import that set, and only advertise the api library to the world. Thus: function export, without any special mechanism for function export.
(In reply to comment #8) > > In answer to the question he poses (why allow more than one module per ns?) > the short answer is because function namespaces and physical partitioning > have nothing to do with one another. (If that were true, then in addition to multiple modules implementing a single namespace, you could also have a single module implementing multiple namespaces. But that's beside the point, I think.) > If your only choice is between putting all > 20000 lines of XQuery into a single file or inventing random distinct namespaces > just so you can partition the physical file (which will drive all the clients > of that module completely spare trying to remember which function is in which > namespace), you have no sane solution to a basic development issue. Right, and if the Comment #5 wording is adopted, and you want portable code, that choice *is* your only choice, so you have no sane solution to the issue. > The current design also has the salutary effect of allowing one to hide all > the "internal functions" in one physical file, have a "api library" import that > set, and only advertise the api library to the world. Thus: function export, > without any special mechanism for function export. If the api module and the internal module have the same target namespace, then importing that namespace isn't guaranteed to import the api module only: -- it might (and under the prior semantics, it would) import both modules, in which case the internal functions wouldn't be hidden; or -- it might import only the internal module, in which case the client code (using only the functions defined in the api module) would break.
Could I have a response to my previous comment on this issue?
The WG considers this issue closed and intends to make no change in this area. If you not satisfied with this resolution, please let us know. In answer to your question: The fact is that there is much that is implementation defined in this area, starting with the basic point that the entire module feature is optional. Further, URI resolution is implementation defined as well. So, even if the spec were to insist that location URIs were more than hints and they must be obeyed, there is no guarantee that the URI resolver in two implementations would work as expected. It it not reasonable to expect to be able to pick up a large application (i.e. one dependent on modules) from one implementation and drop it down on another and expect it to work with no knowledge of the implementation. This goes far beyond modules: There are plenty of other implementation-dependent/defined features in the XQuery language that can dramatically affect how or whether applications will work, e.g. static typing, URI resolution wrt fn:doc, locating schemas and whether to apply them at all. I don't believe, for modules, this is different in kind from what you find in other programming languages, although it certainly differs in degree. The C _language spec_ does not tell you what you get when you put #include "foo.h" into your program or where it will be located: your compiler documentation does. Speaking only for myself, I would have preferred a design that made locations more than just hints, but given the range of contexts in which XQuery implementations are living -- as self-embedded application languages working off file systems or off their own internal stores, as queries embedded in the context of SQL engines, as transformation engines inside application servers, and others besides -- it is difficult to come up with hard and fast rules that won't make certain reasonable implementation choices impossible. The price application developers have to pay for this is the possibility of having to modify applications to work in certain implementation contexts. The current design has the virtue of making reasonable implementations possible.