[EMAIL PROTECTED] wrote: > 2. A good job has been done with XML Schema; some scaffolding is > present, but little else has been done for DTD's. > > In this message I'll focus on 1, with a view to summarizing > some of the off-list discussions that have occurred, and proposing a > way forward. I'll send a subsequent message on point 2, since that > topic is entirely separate and I'm really hoping we can draw in some > DTD gurus--IMHO lack of DTD expertise is probably the biggest reason > we haven't had much progress on this front.
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. > (a) Don't (need to/want to) know about potential pitfalls; just want a > parser that works reliably. The sort of application for which XML > isn't essential or performance isn't critical. This kind would want a > null implementation. Yep. And this would be equivalent to the default implementation where no grammar caching occurs. > (b) Want performance, but don't have knowledge/time to customize. > This would be the sort of application for which XML is critical--maybe > a SOAP server or some such; might be written to use a wide variety of > parsers, and wants to exploit abilities where possible without too > much development overhead. These would be the sort that would want a > good default implementation, preferably easily available through > standard API's, and would not use preparsing. Not want preparsing? or don't care about the details of what the parser does in order to preparse and store grammars? 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); or they are preparsed. Now whether the details of this are hidden from the user or not is open to debate. > (c) Performance is critical, and so is stability, but perhaps there's > not time to develop a custom XMLGrammarPoolImpl. These would be the > sort of applications that would use grammar preparsing and locking. 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. > (d) The super-application that wants everything its own way. Very rare in my opinion but it may come up. -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
