Ok, if so, how could we understand the two statement I've mentioned. 
For example,

A <a title="http://www.w3.org/TR/xquery/#dt-module-import
module import" href="http://www.w3.org/TR/xquery/#dt-module-import" target="_blank" >module import imports 
  only functions and variable declarations; it does not import other objects 
  from the imported modules, such as <a title="http://www.w3.org/TR/xquery/#dt-issd
in-scope schema definitions" href="http://www.w3.org/TR/xquery/#dt-issd" target="_blank" >in-scope schema definitions or 
  <a title="http://www.w3.org/TR/xquery/#dt-static-namespaces
statically known namespaces" href="http://www.w3.org/TR/xquery/#dt-static-namespaces" target="_blank" >statically known 
  namespaces.
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.


and

  It is a <a title="http://www.w3.org/TR/xquery/#dt-static-error
static error" href="http://www.w3.org/TR/xquery/#dt-static-error" target="_blank" >static error [<a title="http://www.w3.org/TR/xquery/#ERRXQST0036
err:XQST0036" href="http://www.w3.org/TR/xquery/#ERRXQST0036" target="_blank" >err:XQST0036] to import a 
  module if the importing module's <a title="http://www.w3.org/TR/xquery/#dt-is-types
in-scope schema type" href="http://www.w3.org/TR/xquery/#dt-is-types" target="_blank" >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.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?

Thanks
  Harrison

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





The constraint:
 
For a given query, define 
a participating ISSD as the <a title="http://www.w3.org/TR/xquery/#dt-issd
in-scope schema definitions">in-scope schema definitions of a module that is used in evaluating the query. If two 
participating ISSDs contain a definition for the same schema type, element name, 
or attribute name, the definitions must be equivalent in both 
ISSDs."
 
applies to the query as a whole. Each module in the query 
has its own (participating) ISSD. This rule says that the ISSD for one module 
must be consistent with the ISSD for every other module; specifically, if two 
modules import definitions of a particular schema type, then those definitions 
must be "equivalent" (which isn't precisely defined, but that's another 
problem).
 
Michael Kay
http://www.saxonica.com/



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


  Hi, Micheal, thanks for your reply, 
  however I am still in doubt.
According to the definition of 
  "participating ISSD", it's a kind of 
in-scope schema definitions, 
  
then whether 
in-scope schema definitions include schemas 
  imported in other imported modules?

There are two 
  statement in spec.:

  A <a title="http://www.w3.org/TR/xquery/#dt-module-import
module import" href="http://www.w3.org/TR/xquery/#dt-module-import" target="_blank" >module import imports 
  only functions and variable declarations; it does not import other objects 
  from the imported modules, such as <a title="http://www.w3.org/TR/xquery/#dt-issd
in-scope schema definitions" href="http://www.w3.org/TR/xquery/#dt-issd" target="_blank" >in-scope schema definitions or 
  <a title="http://www.w3.org/TR/xquery/#dt-static-namespaces
statically known namespaces" href="http://www.w3.org/TR/xquery/#dt-static-namespaces" target="_blank" >statically known 
  namespaces.and

  It is a <a title="http://www.w3.org/TR/xquery/#dt-static-error
static error" href="http://www.w3.org/TR/xquery/#dt-static-error" target="_blank" >static error [<a title="http://www.w3.org/TR/xquery/#ERRXQST0036
err:XQST0036" href="http://www.w3.org/TR/xquery/#ERRXQST0036" target="_blank" >err:XQST0036] to import a 
  module if the importing module's <a title="http://www.w3.org/TR/xquery/#dt-is-types
in-scope schema type" href="http://www.w3.org/TR/xquery/#dt-is-types" target="_blank" >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.From upon two statement, we could 
  make the conclusion that 
in-scope schema definitions should not include 
  schemas imported in 
  other imported modules, otherwise [<a title="http://www.w3.org/TR/xquery/#ERRXQST0036
err:XQST0036" href="http://www.w3.org/TR/xquery/#ERRXQST0036" target="_blank" >err:XQST0036] 
  
will 
  be unnecessary, therefore 
  "participating ISSD" should also not include schemas 
  imported in other imported modules, right?

So I think two modules 
  import identical type qname with different difinition is not an error, 
  
unless variables with one of the types are passed to another 
  module.

The section 2.2.5's constraints that require the types derived from validating 
  input documents to be consistent with those that are imported into the static 
  context helps me to clarify
another problem, 
  thanks.




  2008/1/2, Michael Kay <mike@s... >:
  
    
    I think 
    the mailing list at talk@x... would be a 
    better place for such a question. As it happens, your question is very 
    similar to one raised this morning on that list by Weihua Jiang of 
    Intel.
     
    I 
    believe that your query violates the rule in the penultimate bullet of 2.2.5 
    in the XQuery specification: 
     
    "For a given query, define a 
    participating ISSD as the 
in-scope schema definitions of a module that is used in 
    evaluating the query. If two participating ISSDs contain a definition for 
    the same schema type, element name, or attribute name, the definitions must 
    be equivalent in both ISSDs."
     
    The 
    introductory paragraph of 2.2.5 says "This specification does not define the result of 
    a query under any condition in which one or more 
    of these constraints is not satisfied." - in other words, it's an error to have two different types with the 
    same name, but it's not an error that an implementation is required to 
    detect and report. So it's not surprising that you get different results 
    from different processors, nor that the results are "obviously 
    wrong".
     
    Section 
    2.2.5 also imposes constraints that require the types derived from 
    validating input documents to be consistent with those that are imported 
    into the static context.
     
    Michael 
    Kay
    http://www.saxonica.com/
 

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


      
      Hi, I come up with a problem when reading XQuery spec., 
      following is my case:

a.xq:

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

b.xq:

module namespace mb="http://www.w3.org/TestModules/moduleB 
";
import 
      module namespace ma=" 
      http://www.w3.org/TestModules/moduleA" at "a.xq";
declare function 
      mb:funcB()
{
   ma:funcA() treat as 
      xs:integer
};

c.xq:

declare namespace mc=" 
      http://www.w3.org/TestModules/moduleC";
import module namespace 
      mb="http://www.w3.org/TestModules/moduleB " at 
      "b.xq";
import schema namespace simple=" http://www.w3.org/XQueryTest/simple
 " at 
      "schema_c.xsd";

declare function mc:funcC()
{
  
      mb:funcB() instance of 
      simple:myType
};

<result>{mc:funcC()}</result> 
      

schema_a.xsd:

<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" 
      
>
  <xs:simpleType name = 
      "myType">
     <xs:restriction base = 
      "xs:int">
      <xs:minInclusive value = 
      "1"/>
      <xs:maxInclusive value = 
      "50"/> 
    </xs:restriction>
   
      </xs:simpleType>    
      
</xs:schema>

schema_c.xsd:

<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"
>
  <xs:simpleType name 
      = "myType">
     <xs:restriction base = 
      "xs:int"> 
      <xs:minInclusive value 
      = "51"/>
      <xs:maxInclusive value = 
      "100"/>
    </xs:restriction>
   
      </xs:simpleType>    
      
</xs:schema>

Main module is c.xq, what should be 
      output?
The key problem is, whether we need to keep different type 
      definition in each module,
in case imported types have same name and 
      actually are different?
I tried some XQuery processors, they all give 
      different result and most of them are obviously wrong... 

Another 
      further problem is, if we choose to ignore types imported from other 
      modules, while we need to recognize types bring by XML documents,
then 
      it seems confusion when we handle a returned value of a function, as we 
      need to distinguish where the value comes from: 
defined by module or 
      get from 
document.