Re: [xml-dev] Problem about imported schema type when processing XQuery

["he harrison" <harrison076@gmail.com>]

Oh, sorry it seems that I miss a "s" when I say "participating ISSD", so actually
we have only minor difference, let me correct:
For a module, its participating ISSDs include the (1),(2),(3) I've mentioned in last reply,
while your opinion is that its participating ISSDs include:
1 the module itself imported schema definitions
2 XML document imported schema definitions
3 all schema definitions imported in imported modules

so the only difference is (3), your opinion is a static one while my understanding
is a dynamic one, right?

Actually I think our different understanding rooted from the different understanding
about the "module" concept in XQuery.

You consider XQuery's module as a 
complete equivalance to XSLT's module, which should be "included" in 
another module then compile, 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", when imported, only the top level variables and function signatures are
affected by type redefine mechanism, the local variables in functions should not be affected.

The reason why I make such conclusion is from following XQuery spec statement:
1 "A 
module import imports only functions and
variable declarations; it does not import other objects from the
imported modules, such as in-scope schema definitions or 
statically known 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
error [err:XQST0036] to import a module if the
importing module's in-scope 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. 

You once commented that this is just for making seperate compilation of modules easier,
I actually did not see much easier, since when we treat it as "white box", then there 
must be a global schema definition table and locating any type should already be quite
easy.

Thanks
  Xin

2008/1/3, Michael Kay <mike@saxonica.com>:

>       Ok, let me make it more concise. It's true that the ISSD is a static
context, while
        participating ISSD, in my understanding, include following schema
definitions:
        1 the module itself imported schema definitions
        2 XML document imported schema definitions
        3 those schema definitions imported in imported modules, and used to
describe variable
         values and function arguments and return values(typically by
subtype substitution).

I can't see where you get that from. The specification states "define a
'participating ISSD' as the in-scope schema definitions of a module that is
used in evaluating the query." So a participating ISSD is the ISSD of a
module, and the ISSD of a module is the set of schema definitions imported
into that module. That is, it is (1) above, and not (2) or (3).

(I don't know why the adjective "participating" is causing such trouble.
There are an infinite number of modules in the world, and each has an ISSD.
We are only interested in the modules that participate in the query, and we
describe the ISSDs of these modules as participating ISSDs. Perhaps you are
thinking of the 'participating ISSDs' as some kind of union or amalgamation
of the individual ISSDs? I don't think that's intended: it's simply a set,
one ISSD for each module in the query).

>       What's more, even if we could forgot the scenario that two types in
two files have identical  QName,
        we still could not avoid  the  "redefine" mechanism in schema, which
did allow two types
        have identical name while have different different definitions.

The semantics of xs:redefine are pretty horrible and are not especially well
defined even in a pure validation scenario; in an XSLT or XQuery scenario
the specification is open to a great deal of interpretation. But what the
schema specification does say quite explicitly is that xs:redefine is
pervasive - that is, all references to the type are treated as references to
the redefinition, never to the original. In fact, the specification states
that a schema component that has been redefined will have no {name}, thus
avoiding the problem you describe of two components having the same name.
See Schema Representation Constraint: Individual Component Redefinition,
clause 1.1.

I think there are two ways a query processor can legitimately handle
xs:redefine. One way is to build a single schema (= a set of schema
components) as the union of all the imported schemas, and apply redefine
pervasively within that schema. Then all references to a redefined component
are treated as references to the redefinition. The other way is to treat
each module as having its own schema (= a set of schema components), in
which case some modules might see the redefined component and others the
original. If you do that, then you have an inconsistency under the rules of
XQuery 2.2.5, because the ISSDs of two different modules see different types
with the same name.

Michael Kay
http://www.saxonica.com/