I can give you one data point. I'm working with a client who is using an XML datafeed. The schema is locked but lots of documents are exchanged. In this case, locking the grammar is important as is caching. Ideally, there would be a method call that takes a namespace and URI and adds that namespace to the cache. Preparsing, etc happens via the method call.
One other comment here. We're venturing into an area where we are all guessing about what's important. One nice thing about open source is that we can try to put something out, *ask for feedback* and then change it. We may just stick it in CVS and ask the bleeding edge guys to get a nightly build and try it. Then we can come back and figure out how to do it better. Feedback good. Ted On Thu, 2002-03-21 at 11:32, [EMAIL PROTECTED] wrote: > Hi Andy, > > > > > Even though I don't have a lot of time for active development, > I'm always available to help design the DTD side of grammar > caching. I have thought about this problem a lot previously so > I know what you'll be facing to implement this functionality. > > Right on! I'll post some thoughts in the next message. > > >Yep. And this would be equivalent to the default implementation > where no grammar caching occurs. > > Right. This is what you should get if you just create a parser with > StandardParserConfiguration. > > > Either they want grammar caching or they don't. In the case that they > do, then either the grammars are added to the cache the first > time they are seen (not very likely and prone to problems); > > Why is this either unlikely or prone to problems? Consider an app that > expects docs from only a very limited grammar set; say a configuration > processor, or an XML query processor, or something in that vein. All it > cares about is making sure docs it gets conform to a grammar in its set; if > they're not in the set it rejects them. > > With a regular parser, the way to do this would be to implement an > EntityResolver which would identify which grammar the doc required; either > reject the doc accordingly or spit an InputSource at the parser. With > xerces, all it needs to do is send the grammar InputSource at the parser > once, and the parser will identify the grammar that's required > subsequently; the app's EntityResolver then will only get called on > grammars the parser can't identify--grammars which it likely wants to > reject. The only potential snag here is that the parser might try to use > an incorrect grammar on a document; but, with schemas at least, since we're > keying on namespaces the probability of this happening seems very > low--although it certainly does deserve a caveat in our documentation. > > I would submit this is a pretty common case. If we provide a configuration > with grammar-caching functionality, the app gets all this goodness simply > by setting a system property--it will require no specialized code for > xerces, and won't even have to detect that it's xerces under the covers. > > >I find option (a) and option (c) being the most popular choices. > Option (a) is for no grammar caching and option (b) would be for > general grammar caching. > > Do you mean (c) here? Obviously you and I have somewhat different takes on > how this stuff will be used; it would be great if a user (or potential > user) of grammar caching could pick up this thread... > > >> (d) The super-application that wants everything its own way. > > >Very rare in my opinion but it may come up. > > I think you're right. Which is why I scratched my head over adding > hashCode() to XSDDescription. :-) > > Since you didn't comment on my suggested changes, I'll assume you're all > right with them--even if you didn't agree with my use-cases. :-) > > 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]
