W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2004

[QT] CER-04 Module import

From: Mary Holstege <mary@cerisent.com>
Date: Sun, 15 Feb 2004 11:27:10 -0800
Message-ID: <16431.51214.902000.524993@gargle.gargle.HOWL>
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"
      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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:17 UTC