Hi Pavani,

Great to hear you're interested in helping!

>If we plan to use XMLGrammarDescription as the key, don't you think
>we have to change the signature of XMLGrammarPool's
>cacheGrammar(String grammarType, Grammar[] grammars) method
>to
>cacheGrammar(XMLGrammarDescription[] descriptions, Grammar[] grammars)

Good point.  This gets me to thinking:  XMLGrammarDescriptions make sense
when we're asking for something--when we need to provide all possible
context for what we're looking for.  But if I'm a validator passing some
grammars I've built back to the cache, it's grammars I'm passing; the fact
that they have a particular systemId wouldn't interest me much.  In fact,
such a validator would have to squirrel away the entire
XMLGrammarDescription object's contents in order for this to work--and this
is info it wouldn't otherwise need.

So now I think we should use something simpler; perhaps namespaces for
schemas, internal subset strings for DTD's in our default implementation.
This should be plenty sufficient for our purposes, while still keeping the
caching interface as clean as possible   (I should also note that, if the
Grammar pool *does* want to keep track of GrammarDescriptions, then it can
clone them itself when a validator requests a grammar that it doesn't have,
then match the grammarDescription it's stored with the grammars it gets
back from the validator in the cacheGrammar method.)

> Moreover, we need not pass the grammarType 'cause the application can
>get it from the getGrammarType() method.

True.  The only point I'd make is that we're expecting grammars *of one
type* to be passed back in this method; this signature perhaps reinforces
that fact.  And otherwise the user would have to do something like

     if(grammar[0].getType() ...

which looks a bit unclean to me.  Anyone else with thoughts?

> I can see XMLGrammarConfiguration, XMLDTDValidator, XMLGrammarPool and,
may be, XMLSchemaValidator are the classes which will need major work.

Some others too:  It would be nice if DOMASBuilder was brought under this
framework, instead of using the "custom" methods in XMLGrammarPoolImpl that
it does now.

To start with, would you like to fill out all the blank methods in
impl.validation.XMLGrammarPoolImpl?  In the meantime I'll think about
XMLGrammarPoolConfiguration if no one else has input.

I think the best strategy is to try and get schema up and running first,
then turn our guns on the DTD validator and see how much resistance it puts
up.

Cheers,
Neil




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to