Re: multiple modules with the same name

Michael Rys wrote:
> Like in the case of XML Schema, the number of actual library files is
> inconsequential since they will be presented as one unit for the purpose
> of the import. The management of the modules is outside of the XQuery
> specification's scope.

The choice is between
(1) a LibraryModule has a unique name, and thus a unique identity,
independent of the variables and functions defined in it; or
(2) a LibraryModule in itself has no name or identity, but only
*contributes* definitions to a namespace.

Either alternative works, but there are pragmatic issues.

* In case (2) then a ModuleImport needs to import the set of definitions
exported by LibraryModules with a matching name.  In that case it is
possible for the set to be empty.  This makes it difficult to catch a
typo in a ModuleImport.  Instead, we have to wait until the importing
modules tries to use a name in the imported namespace.  It is possible
for a processor to emit a warning on importing an empty module, but
this is problematical.

* If a LibraryModule does not have its own name then tools such as
compilers, dependency checkers, and even old-fashioned 'make' becomes
more difficult to use and write.  If a LibraryModule has its own name,
then an implementation can specify a mapping for where it should be,
and where to put compiled versions of it.  If it does not have its
own name, things become much more complicated.  Note how Java class
names are traditionally mapped to file names, and how a URL is mapped
by a browser to a file name.  This does make things easier to
understand, explain, and manage.

* If a LibraryModule has its own name, an implementation can easily
compile it to unique own file or directory.  E.g. a LibraryModule
can be compiled to a Java class or a dll.  Without its own name,
each function or variale definition has to be compiled to a separate
file, since they are the only entities with non-anonymous identity.
This may be significantlty less efficient.  In my case I would rather
compile a LibraryModule to a Java class, than compile each function
to its own class.

* If an import module can resolve to an unknown number of
LibraryModules, that implies finding all the modules that match
some URI.  (That is unless we we punt and just look up variables
and functions individually.)  Finding all the entities maching a
URI is a search operation that URLs traditionally have not supported.

* Finally, if interpretation (2) is the correct one, then I don't
see any point to having ModuleDecl and ModuleImport in the language.
The don't provide any power or convenience that I can't get by
using namespace declarations alone.  For example in my Java
implementation, I can just map each expanded QName to a Java
class names, and I can find each function using its class name.
The module import provides no are organization or convenience,
so just drop it:  it's just confusing clutter.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Received on Tuesday, 6 May 2003 22:11:49 UTC