it seems to me that we could fix this problem by changing the following line (inside IGXMLScanner::loadGrammar and SGXMLScanner::loadGrammar) from
fGrammarResolver->useCachedGrammarInParse(false);
to
fGrammarResolver->useCachedGrammarInParse(toCache);
In fact, if we are going to cache the grammar after loading it, we should re-use the grammars already found in the pool, or the exception will occur (or, if we decide to silently skip the caching of a duplicate grammar, an inconsistent set of grammars will be cached).
I am inclined to check in this change, unless Khaled has something to say about it.
Alberto
At 13.35 07/10/2003 +0100, Gareth Reakes wrote:
Hi,
> Example: > schema B includes schema A > schema C includes schema A > > loadGrammer() of schema B failes because target namespace of schema A is > already known.
I have also come across this issue, all be it in a slightly more convoluted way.
>
> I helped myself with adapting the GrammarResolver::cacheGrammars() function.
> The new behaviour is to ignore caching of a new schema that is already
> known, and not to throw an exception as in original code.
> With this little change anything (preparsing and validation) works fine.
As did I, although this has some clear problems if you have a hierarchy of schemas and are including from parts of it.
> > Here my questions: > > - Are there any reasons why GrammarResolver throws an exception if it > should add an new Grammar to the cache? (Maybe I don't see other > impacts yet)
Yes, it it relates to your suggestion below. We currently do not have the ability to test for equality of the components. The schema spec has this to say:
NOTE: The above is carefully worded so that multiple <include>ing of the same schema document will not constitute a violation of clause 2 of Schema Properties Correct (�3.15.6), but applications are allowed, indeed encouraged, to avoid <include>ing the same schema document more than once to forestall the necessity of establishing identity component by component.
So I think that we are currently incorrect by not allowing this. In fact, one of out products in development requires this functionality. Xerces-J has a problem with it as well.
> > - Wouldn't be this change be useful for all xerces users? > > - I my eys an additional merging functionality would be useful, that > updates and enhances definitions of an already cached grammar. > Example: file a.xsd and b.xsd define elements of the same target > namespace. It would be useful if the internal grammar representation > would be a union of file a and b What do you think?
I think so as well, but we would have to do some work to be able to establish identity of the components.
Gareth
-- Gareth Reakes, Head of Product Development +44-1865-203192 DecisionSoft Limited http://www.decisionsoft.com XML Development and Services
--------------------------------------------------------------------- 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]
