[EMAIL PROTECTED] wrote: >Hi all, > >A while ago we decided to defer the loading of schema grammars, until such >grammar is actually referenced by the instance document. This seemed to be >a good idea, but bug 10433 made me think more. > >In the example attached to that bug (option 1), schema document B imports >A; the instance document has an xsi:schemaLocation for B; and the root >element is from namespace A. This is a perfectly valid document, but Xerces >reports an error saying "can't find declaration for the root element". > >The reason is that we defer the loading of B, hence grammar A is not loaded >either. > >Is there a solution to this while still deferring the loading of schema >grammars? Or do we have to abandon this idea? > > I don't think that bug 10433 is a bug, but is a usage error (or unreasonable expectation). However, you could make Xerces-J recover gracefully from that without significantly reworking schema loading.
What you are faced with is a bad hint. The document author could have provided an xsi:schemaLocation="http://www.example.org/namespaceA http://www.example.org/schemaB.xsd"; or xsi:schemaLocation="http://www.example.org/namespaceA http://www.example.org/schemaB.xsd http://www.example.org/namespaceB http://www.example.org/schemaB.xsd";. Either of those hint should have allowed to make the connection between an element in namespace A with its definition via import (and potential redefinition or extension of substitution groups) in schemaB even though schemaB.xsd target namespace would have been namespaceB. So, the question becomes what should the parse do if there are no matches for a namespace in the in-scope schema locations? You could have a fallback that if there is no match on the namespace but there are in-scope schemaLocations, that you load them (all?) before giving up. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
