Re: multiple modules with same namespace

Don Chamberlin wrote:

> Both the  "import schema" and "import module" clauses will be modified 
> so that they take a single "target namespace" (a URI) and zero or more 
> "location hints" (also URIs). It will be an error for two "import 
> schema" clauses, or two "import module" clauses, to specify the same 
> target namespace. The location hints may be interpreted (or ignored) in 
> an implementation-dependent way. Thus, for example, if a module with 
> target namespace "A" is defined by two physical resources at locations 
> "B" and "C", a user might write:
> 
> import module "A" at "B", "C";
> 
> Each of the physical resources imported must contain a syntactically 
> valid module definition that specifies the expected target namespace. 
> However, if two different resources define the same qualified name (for 
> example, two definitions for an element named a:foo), an error is raised.
> 
> The new rules will appear in the next XQuery Working Draft. Please let 
> us know if you are satisfied with this resolution of your issue.

Not fully.  There is still the issue: is it possible to write portable 
library modules, without having to modify them for each platform?

If the language allows only a single "physical resource" containing a 
single module definition for any given namespace, then it is easy to 
define a mapping from namespace to resource location.  The namespace can 
be mapped to a unique classname or relative filename.

If there can multiple physical resources for a given namespace, then the 
implementation cannot use the namespace alone to locate the module. It 
must use the location hints, or an external configuration file or 
database.  Neither is portable.  One should be able to "deploy" a set of 
modules into a directory, and have XQuery be able to find them without 
having to edit each source file or a configuration file.  (I might have 
to edit a configuration file to specify a search path, but I shouldn't 
have to do that for each module.)

A suggestion: how about a non-normative addendum suggeting a convention 
for file layout and location hints?  This would be similar to the 
specification in Chapter 7 of the Java language specification:
http://java.sun.com/docs/books/jls/second_edition/html/packages.doc.html#37758

My suggestion:

A module is referenced using a "module name", which is a URI (absolute 
or relative).  How an implementation "deferences" a module name to get 
an actual module is implementation dependent:  implementations may 
support "file:" and "http:" URLs with the usual meaning; they may 
resolve a relative URI using an implementation-defined base URI; they 
may provide a mechanism to map a URI prefix to some other URI prefix or 
a "search path".  An implementation may also map an "extension" 
representing an XQuery source file (".xql" or ".xq" should be 
recognized) to other extensions used for pre-compiled modules.
The Base URI of a module if a base uri isn't explicitly specified should 
be its module name.
If a location hint in a import module or import schema is a relative URI 
it should by default be resolved relative to the importing module's Base 
URI.  An implementation may also support specifing a search path for 
relative URIs.  A location hint with an absolute URI may be found as 
above.  For best portability it is recommended to specify location 
hints, and to use relative URIs that look like source file references. 
E.g.:
   import module "http://x.org/math" at "utils/trig.xql";
There need not be any relationship between module names and the target 
namespace of an imported module.

(I don't see any way to find a module given just it target namespace and 
no location hints, except using an implementation-specific table or 
database, given that modules are not identified by their target namespace.)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Received on Sunday, 8 February 2004 11:06:43 UTC