OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Problem about imported schema type when processing XQuery module import

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


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS