- From: Mary Holstege <mary@cerisent.com>
- Date: Sun, 15 Feb 2004 11:27:10 -0800
- To: public-qt-comments@w3.org
Query Lang [4.9] Module Import
"It is a static error if the target namespace of the module to be imported is
the same as the target namespace of the importing module. [err:XQ0056]"
Request that this sentence be struck. It introduces no useful constraint that
is not already covered by existing rules, but introduces a constraint that is
highly detrimental to application development.
The analogy to imagine here is that a module namespace is a Java package name,
and the individual module instances are individual Java classes. This rule is
equivalent to saying that each Java class can only import classes in other
packages. It can import multiple classes from other packages, but not any from
its own package.
Consider a complex XQuery application, where the code is partitioned across
multiple developers. There are a number of cases where module namespaces do
not provide the level of granularity for managing complex code bodies. In these
cases, providing the means to partition the namespace across multiple sources,
and use the module locations in the intuitive fashion (i.e. a file location
locates a file which is syntactically a complete module) provides great benefit.
To get the full benefit of this ability to partition an application namespace
across multiple sources, the decision to forbid importation of modules from the
same namespace should have been reconsidered in the context of the decision to
allow imports of the same module namespace from multiple locations.
Case 1:
Two independent developers, working on different functions.
Developer A: selection-lib.xqy
module "http://example.org/application"
Developer B: display-lib.xqy
module "http://example.org/application"
Syntactically each of selection-lib.xqy and display-lib.xqy is a module,
and scopes its contents as normal.
Application: application.xqy
declare default function namespace "http://example.org/application"
import module "http://example.org/application" at "selection-lib.xqy"
import module "http://example.org/application" at "display-lib.xqy"
The application will see the function declarations and variable names
declared in either selection-lib.xqy or display-lib.xqy. Any name conflicts
will be handled in the usual fashion, raising a static error [err:XQ0037].
We allow this, provided that application.xqy is not itself a module.
Case 1b:
As above, but there are some shared constants that A and B both require.
Developer A: selection-lib.xqy
module "http://example.org/application"
import module "http://example.org/application" at "constants.xqy"
Developer B: display-lib.xqy
module "http://example.org/application"
import module "http://example.org/application" at "constants.xqy"
Application: application.xqy as before
This is forbidden by the offending sentence. Both selection-lib.xqy and
display-lib.xqy will therefore need to repeat the shared declarations, but
this will create a name conflict in application.xqy and raise an error.
Case 2:
Use module to scope function definitions, without introducing need for
separate namespace.
Support library (protected): application-lib.xqy
module "http://example.org/application"
API: application-api.xqy
module "http://example.org/application"
import module "http://example.org/application" at "application-lib.xqy"
Application:
import module "http://example.org/application" at "application-api.xqy"
The application only sees the interface defined in application-api.xqy, and
not (using normal module scoping rules) the non-API functions in
application-lib.xqy. Again, this is ruled out by the offending sentence.
Received on Tuesday, 17 February 2004 11:09:45 UTC