This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We are adding a new appendix for Module Import, at Mike Kay's suggestion. Here is the text (take from the member-only email http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2009Feb/0041.html) From: Michael Kay <mike@saxonica.com> Date: Thu, 12 Feb 2009 16:44:31 -0000 To: <w3c-xml-query-wg@w3.org> Message-ID: <4E01A8DD970D433B8F440D0DB344B19C@Sealion> Following up on discussion of my recommendations at http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2009Feb/0009.html here is proposed text for a new non-normative appendix to appear in the second edition of XQuery 1.0 and in XQuery 1.1 Note that the intended purpose of this appendix is (a) to give users guidance on what they can expect, (b) to give implementors guidance on what users might expect, (c) to improve interoperability of queries. The known behaviour of existing implementations has been taken into account in putting these rules together (and there is apparently a high level of commonality), however this is no guarantee that every product currently works this way. Appendix K Guidance for Handling of Modules (Non-Normative) This specification gives considerable flexibility to implementations in the way that modules are implemented, in particular, in the way that module URIs and their location URIs are interpreted. This flexibility is intentional, because XQuery implementations are designed to operate in a wide variety of environments, and some of those environments impose constraints. Nevertheless, in the interests of interoperability, the Working Group hopes that it will be useful to offer some suggestions for how implementations might choose to interpret the specification, in the absence of implementation factors that make a different interpretation necessary. K.1 Module URIs Generally, Module URIs should be treated in the same way as other namespace URIs. Query authors should use a string that is a legal absolute IRI. Implementors should accept any string of Unicode characters. Module URIs should be compared using the Unicode codepoint collation rather than any concept of semantic equivalence. Implementations may provide mechanisms allowing the module URI to be used as input to a process that delivers the module as a resource, for example a catalog, module repository, or URI resolver. For interoperability, such mechanisms should not prevent the user from choosing an arbitrary URI for naming a module. Similarly, implementations may perform syntactic transformations on the module URI to obtain the names of related resources, for example to implement a convention relating the name or location of compiled code to the module URI; but again, such mechanisms should not prevent the user from choosing an arbitrary module URI. As with other namespace URIs, common practice is often to use module URIs whose scheme is "http" and whose authority part uses a DNS domain name under the control of the user. The specifications allow, and some users might consider it good practice, for the module URI of a function library to be the same as the namespace URI of the XML vocabulary manipulated by the functions in that library. K.2 Multiple Modules with the same Module URI The specifications allow several different modules with the same Module URI to participate in a query. Although other interpretations are possible, 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. If one module contains an "import module" declaration for the module URI M, then all global variables and functions declared in participating modules whose module URI is M should be accessible in the importing module, regardless whether the participation of the imported module was directly due to this "import module" declaration. There should only be one instance of a global variable with any given name. For example, if a global variable V is initialized using an element constructor, then there should only be one instance of this element, even if the module in which V is declared is imported by several other modules. (A different approach to this might be used in an environment where a group of modules can be compiled as a unit; in such cases a module used within the compiled unit might be considered distinct from an instance of the same module imported from elsewhere in the query.) K.3 Location URIs The term "location URIs" is used here to refer to the URIs in the "at" clause of an "import module" declaration. Products should (by default or at user option) take account of all the location URIs in an "import module" declaration, treating each location URI as a reference to a module with the specified module URI. Location URIs should be made absolute with respect to the static base URI of the query module containing the "import module" declaration where they appear. The mapping from location URIs to module source code or compiled code MAY be done in any way convenient to the implementation. If possible given the product's architecture, security requirements, etc, the product should allow this to fetch the source code of the module to use the standard web mechanisms for dereferencing URIs in standard schemes such as the "http" URI scheme. When the same absolutized location URI is used more than once, either in the same "import module" declaration or in different "import module" declarations within the same query, a single copy of the resource containing the module should be loaded. When different absolutized location URIs are used, each should result in a single module being loaded, unless the implementation is able to determine that the different URIs are references to the same resource. No error due to duplicate variable or functions names should arise from the same module being imported more than once, so long as the absolute location URI is the same in each case. By default, implementations should report a static error if a location URI cannot be resolved. However, this is not intended to disallow recovery strategies being used if appropriate. K.4 Cycles It is not an error to have a cycle in the import graph, either at the level of module URIs or at the level of location URIs. The only rules concerning cycles affect the relationships between functions and variables defined in different modules.
I'm marking this bug as RESOLVED/FIXED. The bug was created only to provide a "hook" for the corresponding Erratum in the XQuery 1.0 Errata document. I will also immediately mark it CLOSED.