Re: multiple modules with same namespace

Dear Per,

This is a response to the following message, which you posted to the XML
Query Working Group's comments list:

    http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0151.html

as follow up to a response to Don Chamberlin's note

    http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0133.html

The XML Query Working Group considered your comment and has decided not to  
make
the specific changes you request.

We do expect that some implementations will behave just as you suggest. We  
also
expect implementations in which that would not be appropriate (e.g. all  
modules
are available as some kind of stored procedure, all keyed off the module
namespace URI).

We license implementations to use just the module namespace URI to locate
any definitions they may have for that namespace, or to use some of  
location
URIs specified, or all of them, or none at all. Resolution is an
implementation-specific operation, as is the mechanisms by which module
definitions will be bound to namespaces.  We see a value in permitting
different implementations to use different module storage and resolution
strategies that meet their needs, and note the exact parallel with how  
schema
resolution is treated in our specification.

URI resolution is inherently implementation-specific. There is no guarantee
that http://www.example.com/foo.xqy is going to open a connection to the
example.com HTTP daemon listening on port 80; neither is the use of the  
file
URI file://opt/exampleServer/modules/foo.xqy a guarantee that any  
particular
file on the file system will be opened. However tempting it may be to  
require
the location URIs, or specify how they are to be dereferenced if present,
we consider that inappropriate to impose those kinds of constraints on URI
resolvers and XQuery implementations.

We further note that enforcing a logical/physical mapping, even in a
non-normative appendix, still would not address examples such as:

     import module "A"

which is not going to produce a portable result without requiring
some sort of configuration work on the part of the porter in any case.

I would note, however, that we have modified the text so that how modules  
are
obtained from the import statement is now implementation defined, rather  
than
merely implementation dependent.

We appreciate your feedback on the XML Query specifications. Please let us
know if this response is satisfactory. If not, please respond to this
message, explaining your concerns.

Mary Holstege
On behalf of the XML Query Working Group

Received on Thursday, 24 June 2004 08:49:24 UTC