Hi Andy, >There's nothing saying we absolutely need it. It would just >be convenient because we will need an implementation of >XMLGrammarPool internally.
We already have one; why not use that? :-) >And if we need an implementation, >then other people might need one of general use as well. If you think the one we have should live in util instead of impl/validation, I'm completely fine with that. Heck, I'll even make the change. :-) >What about the case where the application sets the grammar >cache? The validators must have a way to access this cache. That's what the XMLGrammarPool is for. An app can always set its own on the configuration, or construct a configuration with one if it likes. This is how the schema validator interacts with the world of grammar preparsing/caching today and it seems to work well enough; no reason to believe it would work any less well if a user-defined pool was used. >However, they should still have a way of accessing the cache >if it's available. Obviously. I have a feeling I'm missing something subtle here. >Just because a component asks for a feature/property does >not mean that the configuration must always support those >features/properties. Our grammar pool is, now anyway, null by default. So I guess this case is taken care of. >Are you suggesting that we basically use the Jar services >method (via the ObjectFactory class) for locating instances? Sure; we could do that. I was actually thinking of using a Hashtable from grammar specification URI's to loader implementation classnames, but there's no reason we can't allow system properties/META-INF/services entries as well. >This has the downside that all of the instances returned are >of the same type within the same VM. I can envision a system >where different caches are given to different parsers within >the same VM. Fine; they can always change the value of the system property that corresponds to the META-INF/services entry at appropriate junctures. So how soon do you figure it'll be before we're ready for me to put at least the core API (the grammar loader) into CVS so we can get moving on this? Cheers! Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
