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