[xquery-talk] about "module" in XQuery spec

[Michael Kay]

I don't think a product has to provide independent compilation to be
conformant (clearly).
 
The specification says that there are consistency requirements such that the
schemas imported by different modules must be consistent with each other in
various ways. Doing such a consistency check can be done when you "link" the
modules together. In the old days "linking" was identified as a separate
step that happened between the compile and run steps; these days it is
usually done as part of loading and running. I think there's definitely an
implication that some consistency checking across modules should be done at
linking time, whenever this might be.
 
Michael Kay
http://www.saxonica.com/


  _____  

From: he harrison [mailto:harrison076 at gmail.com] 
Sent: 11 January 2008 03:01
To: Michael Kay
Cc: talk at x-query.com
Subject: Re: [xquery-talk] about "module" in XQuery spec


Thank you Michael, seems we are now getting closer about this issue.
We all agree that modules in XQuery could be compiled independently.
(Original definition:A module is a fragment of XQuery code 
that conforms to the Module <http://www.w3.org/TR/xquery/#doc-xquery-Module>
grammar and can independently undergo 
the static analysis  <http://www.w3.org/TR/xquery/#dt-static-analysis> phase
described in  <http://www.w3.org/TR/xquery/#id-expression-processing> 2.2.3
Expression Processing. )

Then to what extent this definition "can independently undergo 
the static analysis  <http://www.w3.org/TR/xquery/#dt-static-analysis> phase
" should be followed?

Is it an optional feature of module, or a strict rule for any XQuery
implementation?
This two choices will lead to two design---although for "normal" case the
two
designs will show no difference, but still the two designs are different in
essence, and will
show different behavior under some special case such as "redefine".

For example, if we consider it's a strict rule, then any design 
that could not be implemented in independent module compilation
should be considered as not conformant to spec.
Otherwise, we have to consider that, "can independently undergo 
the static analysis  <http://www.w3.org/TR/xquery/#dt-static-analysis> phase
" is an optional feature of XQuery's module.

Harrison


2008/1/11, Michael Kay <mike at saxonica.com>: 

You are quite correct that the XQuery specification says nothing about how
xs:redefine is handled. This was a deliberate choice, the WG discussed the
matter and decided that nothing useful could be said. This is because the
specification quite deliberately doesn't say, in the case of "import
schema", where the schema components are obtained from, and this means that
if (as in this case) there are different versions of the schema components
available then it's not defined (by the specification) which version is
loaded.
 
I think there are two possibilities:
 
(a) both modules use the same schema components for namespace
http://www.w3.org/XQueryTest/simple, which must be the post-redefine
components. In this case the answer is true.
 
(b) the two modules use different schema components for namespace
http://www.w3.org/XQueryTest/simple  -  one gets the pre-redefine
components, the other gets the post-redefine version. This violates the
consistency requirements documented in the specification; the specification
says that in this situation the results are completely undefined. Clearly a
good processor will detect the inconsistency and refuse to run the query,
but the spec makes it clear that anything might happen - it's like
submitting a random binary file to the Java VM.
 
If you're a user, the clear implication is: don't do this.
 
If you're an implementor, the implication is: either ensure that both
modules use the post-redefine version of the type (which probably isn't
feasible if the modules are compiled separately). Alternatively, detect and
report the inconsistency if you can, but your product is not nonconformant
if you don't.
 
Incidentally, it's no different from having the two modules import the
schema from different locations and picking up different versions; it
doesn't require xs:redefine to trigger this problem.
 
You're right that XSLT handles the issue quite differently. XSLT builds a
single schema that serves all modules, both statically and dynamically. This
has the disadvantage that it makes independent compilation of modules
extremely difficult. But then, it's almost impossible to compile modules
independently in XSLT anyway.
 
Michael Kay
http://www.saxonica.com/ 


  _____  

From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf
Of he harrison
Sent: 09 January 2008 02:48
To: talk at x-query.com
Subject: [xquery-talk] about "module" in XQuery spec



Hi,
I come up with a problem when reading XQuery1.0 spec., following is my case:

a.xq:

module namespace ma=" http://www.w3.org/TestModules/moduleA";
import schema namespace simple="  <http://www.w3.org/XQueryTest/simple>
http://www.w3.org/XQueryTest/simple " at "schema_a.xsd";
declare function ma:funcA()
{
   "40" cast as simple:myType
};

b.xq:

declare namespace mb=" http://www.w3.org/TestModules/moduleB
<http://www.w3.org/TestModules/moduleB> ";
import module namespace ma="http://www.w3.org/TestModules/moduleA" at "
a.xq";
import schema namespace simple=" http://www.w3.org/XQueryTest/simple" at
"schema_b.xsd";

declare function mB:funcB()
{
  ma:funcA() instance of simple:myType
};

<result>{mb:funcB()}</result>

schema_a.xsd: 

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:simple=" http://www.w3.org/XQueryTest/simple
<http://www.w3.org/XQueryTest/simple> "
           targetNamespace="http://www.w3.org/XQueryTest/simple"
           elementFormDefault="qualified" attributeFormDefault="qualified" 
>
  <xs:simpleType name = "myType">
     <xs:restriction base = "xs:int">
      <xs:minInclusive value = "1"/>
      <xs:maxInclusive value = "50"/> 
    </xs:restriction>
   </xs:simpleType>   
</xs:schema>

schema_b.xsd:

<xs:schema xmlns:xs=" http://www.w3.org/2001/XMLSchema
<http://www.w3.org/2001/XMLSchema> "
           xmlns:simple="http://www.w3.org/XQueryTest/simple"
           targetNamespace=" http://www.w3.org/XQueryTest/simple
<http://www.w3.org/XQueryTest/simple> "
           elementFormDefault="qualified" attributeFormDefault="qualified"
>
  <redefine
    schemaLocation="schema_a.xsd">
    <extension base="simple:myType"> 
        <xs:minInclusive value = "51"/>
        <xs:maxInclusive value = "100"/>
    </extension>
  </redefine>
</xs:schema>

What would be the result of this case? 
true? false? runtime error? or implementation define?
Or in another word, would the type in module a.xq should
be redefined by module c.xq's imported schema definition?

This case is related with how to understand the XQuery's "module". 

Let me give my understanding:
XSLT's module, in my understanding, should be "included" in 
another module to compile, could not be compiled independently,
in other words, it's a "white box", its semantic 
depends on where it's included or imported(because its schema type could be 
differently redefined in different including or importing module).
 
While I think XQuery's module is different with XSLT's module, I think
XQuery spec. 
allow its module be compiled independently, no matter where the module is
imported,
module's semantic should not be changed, in other words, XQuery's module
is a "black box", wherever module is imported, module's schema type
definition should not be 
affected by type redefine mechanism.

The reason why I make such conclusion is from following XQuery spec
statement:
1 "A module  <http://www.w3.org/TR/xquery/#dt-module-import> import imports
only functions and variable declarations; it does not import other objects
from the imported modules, such as in-scope schema
<http://www.w3.org/TR/xquery/#dt-issd> definitions or statically known
namespaces <http://www.w3.org/TR/xquery/#dt-static-namespaces> . Module
imports are not transitive-that is, importing a module provides access only
to function and variable declarations contained directly in the imported
module." 

Here XQuery's statement is clearly different with XSLT's statement about
module import. 
In XSLT spec, module imports are transitive while XQuery clearly stated that
they 
are not, so XQuery's module import must be something different with XSLT's
module import.
My thought is, XQuery's module is a "black box" while XSLT's module is a
"white box"

2 "It is a static  <http://www.w3.org/TR/xquery/#dt-static-error> error
[err:XQST0036 <http://www.w3.org/TR/xquery/#ERRXQST0036> ] to import a
module if the importing module's in-scope
<http://www.w3.org/TR/xquery/#dt-is-types> schema types do not include
definitions for the schema type names that appear in the declarations of
variables and functions (whether in an argument type or return type) that
are present in the imported module and are referenced in the importing
module."

Here spec. force user to import interface needed schema types, if we
consider XQuery's
module as "white box", then all imported types in "white box" has already
imported, then 
this statement seems lead to redundancy, however if we consider XQuery's
module
as a "black box", then this statement is quite nature to understand. 

Could someone offer me some comment? 
Many thanks! 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://x-query.com/pipermail/talk/attachments/20080112/085f129c/attachment-0001.htm