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). In other word, those schema definitions that only used to describe imported module's local variables does not belong to importing module's participating ISSD because they have nothing to do

with importing module.

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. Let's take my original case as
an example, if we change schema_c.xsd to:

<xs:schema xmlns:xs="
http://www.w3.org/2001/XMLSchema" 
           xmlns:simple="http://www.w3.org/XQueryTest/simple" 
           targetNamespace="
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>

Then I think the case should be all right, isn't it? So, what's the result?
I think the type "simple:myType" will have different meaning in a.xq
and c.xq, processor should treat them correctly and should not complain, right?


I think if we consider participating ISSD is a dynamic concept, such scenario will be quite
natural to handle.

Thanks
  Xin

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




Sorry, I don't see how you can read the spec that way. ISSD 
is defined "as the 
in-scope schema definitions
 of a module", and "in-scope schema 
definitions" is clearly defined in 2.1.1 as part of the static context. 
This rule is clearly a static rule.
 
You say "I think participating ISSD is not a static concept, but a dynamic 
one", but you don't really explain why you think 
this.
 
Or perhaps I'm misunderstanding you, and you're not talking 
about what the spec says, but about what you think it should say? That's a 
different discussion, of course.
 
Regards,
 
Michael Kay
http://www.saxonica.com/

 


  
  
  From: he harrison 
  [mailto:harrison076@g...] 
Sent: 03 January 2008 
  02:00
To: Michael Kay
Cc: 
  xml-dev@l...
Subject: Re: [xml-dev] Problem about imported 
  schema type when processing XQuery module import


  That still seems obscure....how about my understanding:

My 
  understanding is, for the most part, agree with yours explaination, the 
  difference
is about "participating ISSD", I think participating 
  ISSD is not a static concept,
but a dynamic one, it should not include all schema definitions 
  in imported module, 
but only those schema definitions that passed to 
  importing module along with variables 
or function return values. Those 
  schema definitions in imported modules which are not
used by importing 
  modules do not belong to participating ISSD.
Besides, 
  participating ISSD also include currently active XML document 
  
imported schema definitions, and module itself imported schema 
  definitions.
As to my previous example, module a.xq's imported 
  schema schema_a.xsd is
module c.xq's participating ISSD(because the 
  type are passed by sub typing), 
schema_c.xsd also belongs to c.xq's 
  participating ISSD, while they both contain
same definition for 
  "myType", therefore an dynamic error should be raised.
But if we change 
  a.xq to:

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

then no error should be 
  raised even a.xq and c.xq still have different ISSD that contain
different 
  definition for "myType", because "myType" imported in a.xq will not be 
  
passed to module c.xq therefore will not cause confusion.

I think 
  this understanding is in consistant with both "2.2.5 Consistency 
  Constraints"
and the two spec. statements I've mentioned. 
  

Thanks
  Xin


  2008/1/3, Michael Kay <mike@s...>:
  
    
    Since it does not import in-scope 
    schema definitions from the imported modules, the importing 
module 
    should not see what schema definitions are there in the imported 
    modules.Since they
could not see each other, then how could they decide 
    whether their ISSD is "equivalent"? 
and it seems also meaningless to 
    compare their ISSD because they will not disturb each 
other. 
     
    This may be why the spec doesn't require an implementation to check 
    that the two ISSDs are compatible, but merely says that the results are 
    unpredictable if they are 
    not. 

and


    
      If a module could see the 
      imported module's schema definition, then why spec. still
force the 
      importing module explicitly import necessary schema definition, since 
      these types 
will surely be imported from other module's 
      ISSD?

XSLT took 
      the decision that all imported schema definitions would be available 
      in all modules. However, that makes it harder to do separate 
      compilation of modules. I think the rule in XQuery 
      that each module must import all the schema definitions that it 
      needs is there in the belief that this will make separate compilation of 
      modules easier.
       
      Michael Kay
      http://www.saxonica.com/