[EMAIL PROTECTED] wrote: > But it seems to me that grammar preparsing is analogous in many ways to > pull parsing. Our pull parsing functionality is part of XNI--through the
In what ways? ;) > XMLPullParserConfiguration in the xni.parsers package. So I think we > should have an XMLGrammarCachingConfiguration in the xni.grammars package, > so that preparsing functionality can be exposed in an > implementation-independent way. Let's be sure about what it is that we want to add to the (still experimental) xni.grammars package. The configuration interfaces available in xni.parser are there so that you can drive various API generators (e.g. DOM, SAX, etc) from different parsing pipelines. But in the case of grammar caching, we aren't driving any API generation so having a configuration interface analagous to the xni.parser configs doesn't make much sense to me. However... Currently, in the xni.parser package we have interfaces to define a grammar, a grammar description, and a grammar pool. People would like to be able to pre-parse grammars in a standard way and it seems logical that there should be some companion interface to XMLGrammarPool to help load these grammars. But the only similarity to XMLParserConfiguration would be that the user should be able to register an error handler and entity resolver. > On this new interface I'd like to put clearGrammarPool(), lockGrammarPool > (), unlockGrammarPool(), and a couple of parseGrammar(String type, x) These methods seem to make more sense on the grammar pool interface and not on the interface responsible for loading the grammars. (You note the same thing later.) > methods where x is either a URI or an XMLInputSource. I could live without We don't need a separate method for loading by URI if we have a method that takes an XMLInputSource. I deliberately kept the parsing on the XMLParserConfiguration interface to a single method to avoid the JAXP problem with an explosive amount of parse(...) methods. So I'd like to see any new interfaces follow suit. > the first three, but I think the last two at least are critical. I guess a > parseGrammar(XMLGrammarDescription) might also make sense. My gut reaction is that we don't need this. But I'll think about it more. > I think it might also be nice to put lock, unlock and clear methods on the > XMLGrammarPool interface itself; it would certainly make our implementation > easier if we could assume all grammar pools support these useful and easy > features. I agree. This is where they should be. > All thoughts and comments greatly appreciated! Yes, we definitely need more discussion on this topic. -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
