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

Per Bothner wrote:

> 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'd rather not get into discussing whether the things other vendors have 
asked for in their environments are really necessary, because I don't 
know all the ins and outs of their architectures. But it sounds like 
what I propose above will not be a problem in your environment?

Include makes sense, and is very plausible for a future version of 
XQuery. But it's not time to add it now.

>>> 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.

I'm confused. Two Java modules that depend on each other can be compiled 
independently, linked, and executed. Why do you feel this is different 
for XQuery?

>> 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.

Actually, we have an internal draft for exploratory purposes that says 
one module is the same thing as one module resource, and I was thinking 
of that when I wrote the above sentence. Sorry for the mixup in terminology.

> 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.

The internal draft that we are exploring calls a module resource a 
'module', and 'import module' imports all the modules with a given 
target namespace.

You call that 'a recipe for trouble'. Can you explain more?

Jonathan

Received on Thursday, 26 August 2004 13:40:16 UTC