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 believe that implementors know how to test for circularity, and the
>> exact technique used may depend on their environment.  ...
> 
> 
> It's not a question of implementation, but of specification.  In
> http://lists.w3.org/Archives/Public/public-qt-comments/2004Aug/0026.html
> I gave two examples where I consider the spec needs to be clarified
> as to whether the examples are allowed or not.  Saying it's
> "implementation dependent" does not seem appropriate.


I don't think this is implementation dependent in our spec. Here's my 
interpretation:


| In 4.12 "Variable Declaration" we have:
|
|    If an initializing expression cannot be evaluated because of a
|    circularity (for example, it depends on a function that in turn
|    depends on the value of the variable that is being initialized),
|    a static error is raised.
|
| I assume "circularity" will be defined somewhere, perhaps in the
| formal semantics?

Probably not. See:
http://lists.w3.org/Archives/Public/public-qt-comments/2004Aug/0100.html.

| Is the following a circularity?  (I would assume so, if it is
| to be statically detected.)
|
| module namespace a = "A";
| import module namespace b = "B";
| declare variable a:x := b:y;
|
| module namespace b = "B";
| import module namespace a = "A";
| declare variable b:y := if (true()) then 0 else a:x;

Yes.

| Is this a circularity?  (I assume not.)
|
| module namespace a = "A";
| import module namespace b = "B";
| declare variable a:x := b:y;
|
| module namespace b = "B";
| import module namespace a = "A";
| declare variable b:z := a:x;
| declare variable b:y := 0;

No, this is not a circularity, because the variables do not depend on
each other. The text in question says:

   "If an initializing expression cannot be evaluated because of a
   circularity (for example, it depends on a function that in turn
   depends on the value of the variable that is being initialized), a
   static error is raised.[err:XQ0054]"

This is found in the discussion of variables. When evaluating the
variable definitions, no circularity is found.

>  > For instance, in
>  > an environment that does separate compilation of modules, they may
>  > need to use linking techniques that are less straightforward than what
>  > is needed in an environment that does not have this requirement.
> 
> All the more need for the spec to state whether the examples I gave
> are valid or not.
> 
> I have partial implementation of separate compilation and module
> imports, but I haven't finished it because there are still too
> many questions about how modules are supported to work.  E.g.
> http://lists.w3.org/Archives/Public/public-qt-comments/2004Aug/0030.html

You are right - it is not currently possible to import other module 
resources of the current module. I've discussed this with a few people, 
and I suspect the easiest thing to do is to call what is now a 'module 
resource' a 'module', and allow 'import module' for your own target 
namespace in a library module.

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

I will float this to the Working Group.

> Note that the specification states that circularity raises a *static
> error* so it should be caught at compile-time or at least link-time.

Yes, at least at link time.

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

>> Please let us know if you find this unacceptable.
> 
> Well, you didn't answer the original question ...

OK, I answered it now ;->

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.

Jonathan

Received on Wednesday, 25 August 2004 23:11:28 UTC