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]
