RE: Cross-references among included schema documents

> 
> > But delaying the resolution doesn't change the outcome. If 
> B contains a
> > QName that identifies a component defined in C, and if B 
> doesn't itself
> > include or import C, then the rule tells me that the QName 
> doesn't resolve,
> > and I can't see how delaying the attempt at resolution 
> changes this. The
> > only way I can get the name to resolve is by using a 
> different schema from
> > the one specified in the rule, namely the schema 
> corresponding to schema
> > document A (which includes B and C). The rule as written 
> doesn't allow me to
> > do that.
> 
> It allows you to do so in the context of the schema corresponding to
> A.  

I don't see how one can read it that way. It specifically requires the QName
to be resolved to a component that belongs to the schema corresponding to
the document containing the QName. 

I can see how one could generalize the rule to talk about resolving the
QName relative to some other schema, but the rule as written doesn't do
that.

I can see that you are allowed, or even required, to retry resolution if it
fails the first time, but subsequent attempts at resolution will all fail
the same way, because you are still resolving the QName relative to the same
schema, which is defined in terms of the XML representation.

In practice I am looking for guidance as to what schema I should be using
for resolution. Is it the schema being used for validity assessment (of an
instance)? But that doesn't work either, because if the schema used for
assessment is S, and S imports T, and T imports A, and A includes B and C,
and B contains a reference to a component X defined in C, then X will not be
a member of the set of components in S. So perhaps I should be attempting to
resolve unresolved QNames at each successive stage of schema assembly,
relative to the schema being assembled at that stage? Perhaps this is what
the sentence about "During schema construction" in 4.2.1 is hinting at?

Michael Kay
http://www.saxonica.com/

Received on Monday, 27 September 2004 14:38:17 UTC