[EMAIL PROTECTED] wrote: > > 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.
I said "not very likely" because I see the most common use-case will be that a business application is dealing with documents that use a known set of grammars. Therefore, they would not want any other grammar specified in the document to be read or used in any way. However, upon reflection I can see that there are applications where the XML documents are envelopes based on specific grammars but the contents could be more free-form and not always known beforehand. The "prone to problems" part was in reference to things like the DTD internal subset affecting the declarations in the cached grammar. However, I don't think it's reasonable for the application to expect that the internal subset will be allowed to modify the cached grammar. > >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... Yes, I meant "(c)". > >> (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. :-) Even in the default case, I see a need for a properly implemented hashCode and equals methods on the descriptions. -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
