Hi Andy, Sandy and all, This discussion's been moving along too well recently; I figured it was time I got back involved and made things move slower. :-)
>There's nothing preventing us from writing such a utility >class and then having the grammar cache implementation use >that utility class internally when someone calls the >"loadGrammar" method on XMLGrammarCache. If grammar prePARSing is an end in and of itself--because we're planning to provide some kind of grammar access API some day--then to my mind this "utility" class is definitely something people will want to use. It's their key to getting grammar objects they can use. So let's not have it buried in the util package--where there isn't really anything users would want to play with--and let it live in parsers, with all our other implementation-level stuff that applications are invited to interact with. I don't see a convincing argument for a grammar cache at all. Grammars can be preparsed with our grammar loading implementation and then put in whatever grammar pool the user wishes (with cacheGrammars). We could have a convenience class that does both these things, but there's no pressing need for one IMHO. >I was actually suggesting that >the validator components would only rely on the grammar >cache being in the configuration. But it would be the >parser configuration's responsibility to create the cache, >add a loader for each type of grammar used in that config, >and then adding the cache as a property. We've already got a large number of properties; I'd love to see us avoid another one. I think it's entirely fair for a validator to have to know how to interact with a grammar loader for its particular type of grammar. But I'm not sure it's fair to oblige people who just want to preparse grammars to use configurations; grammar parsing and instance parsing need not necessarily be related. so here's how it would work: Our grammar loading implementation has a mapping between grammar URI's and grammar loader implementations. (it's a little factory if you will). We then use class.forName (or Andy's ObjectFactory) to attempt to construct grammar loaders given the kinds of grammars the user requests--thus no nasty non-layering! And this is very extensible: to add a new grammar preparsing functionality, just subclass this implementation and add a new mapping! To my mind this is a great deal simpler than trying to reconcile grammar pools and grammar caches as properties and resolving where grammar buckets fit in, how validators interact with all these objects etc. We have to remember that eventually maintaining our implementation will be done by other people some day, so it would be cool if we could keep the number of different kinds of objects to a minimum. :-) BTW, I'm +1 for renaming Grammar to XMLGrammar. But I've done my share of renaming back in January; any volunteers? :-) There's my $0.02. 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]
