[Bug 6716] New: Guidelines for Module Import

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6716

           Summary: Guidelines for Module Import
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery
        AssignedTo: jonathan.robie@redhat.com
        ReportedBy: jonathan.robie@redhat.com
         QAContact: public-qt-comments@w3.org


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.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 18 March 2009 20:35:18 UTC