This is actually a very hard problem to resolve. If recursive imports were supported, then you would most likely agree that the imports should be loaded dynamically ie the validity of the schema and the instance document is something that can be determined only at run time. Otherwise cases may be constructed that would cause any processor to crash.
Now section 4.1 requires "...that there be no side effects of such dynamic aquistion that cause the result of assessment to differ from that which would have been obtained from the same schema components acquired in bulk." To return to your example: a imports b b imports c Now suppose d imports a and c' (where c' has the same namespace as c but it refers to a different schema. And assume for the sake of argument that it has a type with the same name as that in c). Suppose d defines a derived type of some element in "a". So it is possible to use it in a schema instance of type "a". Now suppose we want to use the type in "c" that has a name clash with "c'". This should result in an error saying that "c" is incorrect. But the document could be built in another order with "c" coming in first and then "c'". Then c' is in error. This could potentially be resolved by saying both schemas are in error. But a valid instance of "a" could be constructed where no types from c or c' be used and we cannot get the same behaviour as we would if the schemas were loaded in bulk because the processor has to behave dynamically. So the question is "Can dynamic acquisition be implemented without side effects?". If yes, then the spec is ambiguous as to which way to go. If not, then processors should not acquire it dynamically. -Nikhil On Wed, 4 Aug 2004, Jeehong Min wrote: > Xerces developers and users, > > I would like to get your feedback on this. I think that if both Xerces and > XMLSpy are behaving in an acceptable manner, as James says below, then we > have a serious interoperability problem at hand. Suppose someone deploying > a web service uses XMLSpy to manage and edit their WSDLs and schemas, and he > has the import structure that I described in the original email. As far as > they know, the WSDLs and schemas have no problem. Now, suppose someone has > a web service client that uses Xerces under the hood to parse the schemas. > The WSDL and schemas created/edited by XMLSpy are no longer interoperable > with Xerces parser. > > - Jeehong > > ----- Original Message ----- > From: "James Bates" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, August 04, 2004 2:41 AM > Subject: RE: scope of import > > > I just read (again) section 4.2.3 of the W3C XML Schema specification > (part I). Although the issue is not directly addressed (concatenation of > imports), I have the *impression* that it Xerces is entitled to require > that any references to schema components in other namespaces be > accompanied by an appropriate <xs:import> element (in the original > referencing schema). > > Indeed, the <xs:import> instruction seems to do no more that import the > schema *components*, and in fact "... components to be imported need not > be in the form of a schema document; the processor is free to access or > construct components using means of its own choosing." [end of third > paragraph, section 4.2.3] I therefore see no obligation for a schema > processor to take into account <xs:import> elements in the stylesheet > that's being imported. > > On the other hand, I also do not find any obligation for a processor to > require (as Xerces does) that references to schema components from a > foreign namespace be accompanied by an explicit <xs:import> in the > original stylesheet. In other words, the XMLSpy behaviour also seems > acceptable. From the point of view of the XML Schema specification, > XMLSpy is simply using a different means than the available <xs:import> > instruction to discover the definition of referenced schema components > from a different namespace. (Namely it is using the xs:import elements > inside other referenced schema's). > > Conclusion: both are behaving in an acceptable manner? My conclusion is > a cautious one though, as the relevant text in the specification does > not address cascading import elements directly... > > James > > > > -----Original Message----- > From: Jeehong Min [mailto:[EMAIL PROTECTED] > Sent: 31 July 2004 03:56 > To: [EMAIL PROTECTED] > Subject: scope of import > > All, > > Just wanted to verify correct behavior in Xerces. > > Suppose I have 3 schemas, with namespaces A, B, and C. > Schema A imports only schema B. Schema B imports schema C. > Is it legal for schema A to use a type from schema C? > > Xerces says no, saying that types from schema C are not referenceable > from > schema A. I agree with Xerces. However, I have a customer who is using > XMLSpy which does not complain about this. > > So, what is the correct interpretation? > > Thanks, > > Jeehong > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
