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/