Re: qt-2004Feb1159-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-016

Jonathan Robie wrote:


> We're kind of reluctant to think in terms of text include, as you 
> suggest, since that concept makes little sense in some environments.

Well, it doesn't need to be "textual include" literally, just like
a "module resource" isn't necessarily a text file.

I don't believe there is any environment where "include" doesn't make
sense.  XQuery is a programming language with a concrete syntax,
which means the input to the processor is a sequence of characters
or at least tokens, so certainly at that point textual include makes
sense.

Even if the module is stored is some compiled form, at some point it
had to be text, at which point textual include makes sense.

I wouldn't go so far as to say that an include facility is necessary,
but I suspect people will push for it to handle boilerplate (namespace
definitions and schema imports).

>> I don't believe it makes sense for mutually importing modules to
>> be compiled independently, as module imports must be processed at
>> compile-time.  Thus there is no reason to defer circularity
>> detection until link-time.
> 
> Can you spell this out a little? I don't understand exactly what your 
> concern is here.

Just that a set of mutually-dependent modules cannot be compiled
independently, so there is no point in deferring circularity testing
to link time.  I.e. if module A imports module B, then module B must
be available (in either source or compiled form) when compiling A.
If variables V1 and V2 are circularly dependent, then they most be
defined in modules A and B that directly or indirectly depend on
each other.  Hence to compile *any* module in the cycle, *all* must
be available to the compler.  Hence circularity detection can
always be performed at compile time.

> But as you see above, I do think we probably need to modify our document 
> so that you can import modules from your own target namespace.

I assume you meant "import module resources" - and I think this
illustrates the awkwardness of the concept.

I can understand a single "module resource" per module, and either
at most one module per namespace, or allowing multiple modules per
namespace (though the former is a lot easier to implement and I
suspect "deploy").  However, multiple module resources that are
magically combined because they happen to have the same namespace,
that I think is a receipe for trouble.  The number of "last call"
revisions where we still don't have a coherent "module import" modul
should indicate that.  It's not a issue of fixing little mistakes
or ambiguities but fundamental redesign.

It is time for simplification: one module resource per module per
namespace.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Received on Thursday, 26 August 2004 01:07:18 UTC