[xquery-talk] about "module" in XQuery spec
mike at saxonica.com
Thu Jan 10 16:27:24 PST 2008
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
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.
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
I come up with a problem when reading XQuery1.0 spec., following is my case:
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
declare namespace mb=" http://www.w3.org/TestModules/moduleB
import module namespace ma="http://www.w3.org/TestModules/moduleA" at "
import schema namespace simple=" http://www.w3.org/XQueryTest/simple" at
declare function mB:funcB()
ma:funcA() instance of simple:myType
<xs:simpleType name = "myType">
<xs:restriction base = "xs:int">
<xs:minInclusive value = "1"/>
<xs:maxInclusive value = "50"/>
<xs:schema xmlns:xs=" http://www.w3.org/2001/XMLSchema "
<xs:minInclusive value = "51"/>
<xs:maxInclusive value = "100"/>
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
allow its module be compiled independently, no matter where the module is
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
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
Here XQuery's statement is clearly different with XSLT's statement about
In XSLT spec, module imports are transitive while XQuery clearly stated that
are not, so XQuery's module import must be something different with XSLT's
My thought is, XQuery's module is a "black box" while XSLT's module is a
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 schema
<http://www.w3.org/TR/xquery/#dt-is-types> 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
module as "white box", then all imported types in "white box" has already
this statement seems lead to redundancy, however if we consider XQuery's
as a "black box", then this statement is quite nature to understand.
Could someone offer me some comment?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk