Hey Alby,
Do you think this will be sufficient? The problem I am thinking about is this: We have a top level schema A that includes B, C and D. B uses some components from C. We want C to be a legal schema in its own write. To do this it imports A (we could import C, but both are legal). So you now have the problem that the grammars in the URI are not the same. We need to amalgamate them.
Yes, it should be sufficient: for instance,
- you call loadGrammar(D,true). This pushes in the grammar pool D
- you then call loadGrammar(A,true). This would normally parse the grammars A, B, C and D. When you try to cache these grammars, you get an exception because D is already in the pool. After the change in the code, loadGrammar would still load A, B and C, but reuse D from the grammar pool, and the memory pool will contain A, B, C and D (that was already there).
The only constraint you will always have is the one Xerces already has when parsing single schemas: one schema namespace must be represented by one schema URI (so, the schema for namespace D must be the same in all the above steps)
Alberto
I have a bad cold today :( so I hope this makes sense. By all means ask me for more information if this is not clear.
Gareth
On Mon, 27 Oct 2003, Alberto Massari wrote:
> Gareth,
> 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]
>
>
>
-- 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]
