On Wed, 2002-01-09 at 09:04, [EMAIL PROTECTED] wrote: > Hi Ted, > > >I assume that there is a default GrammarPool implementation per parser > configuration. How does an application store a grammar pool so that it > can avoid re-creating one? > > My suggestion would be to have it query the appropriate property on the > Configuration on the first run, then set the property explicitly on > subsequent runs. Do you think that would work?
Seems fine to me -- properties are "the way". The only issue I can see is one of usage mistakes. When is the client code allowed to query the property and get a good GrammarPool? Before parsing? - but this means we have to allow what you suggest below about a GrammarParser. After parsing? How long does the pool live? (Actually this probably isn't an issue since we're strictly sticking to JDK 1.1). > >How can an application create a grammar pool > that is locked to a particular set of grammars? > > If it defines its own it can completely control what grammars get in to the > pool. If I understand what you are saying, you expect the app developer to provide a custom grammar pool implementation. But it seems to me that grammar locking is common enough that it ought to be part of the default implementation. > But a related question is how we go about permitting grammar preparsing in > XNI--grammar caching doesn't make too much sense until you can preparse > your grammars before going live. I guess making some sort of GrammarParser > class in the org.apache.xerces.parsers package might do the trick. Any > other suggestions? I think that some kind of pre-parsing is necessary. > Finally, I suspect we'll want to look at making sure our grammars and > default grammarPool are serializable. At least minimally. There's also the new JavaBeans persistence JSR which allows creation of XML serialization of JavaBeans. Wouldn't it be cool to persist a GrammarPool as XML? Or would that be sick. > >Is a grammar pool sharable amongs multiple parser instances? > > I think the default one should be, but the general case would be up to the > appplication. +1 here. > Cheers, > Neil > > > --------------------------------------------------------------------- > 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]
