Hi Neil, > >> - XMLGrammarPool should be made into an external property. This > >> should be read-only within a parse, but if an application wants to > >> change it between parses it would be caveat emptor. It's > >> conceivable this could be useful, so no point in preventing it. > > > We will add the flexibility to whole grammar caching mechanism > by making > XMLGrammarPool as external property, it would be recognized by different > configurations and validator components. > > Well that's one of the first discoveries I made: You can happily set a > grammar pool implementation today via setProperty(...) on any configuration > that understands GrammarPools, and it'll work fine. i.e., it's as external > as it's going to get.
I think this is true for most of "internal" property like entity-manager, validation-manager etc.. > >We can also change the way JAXP1.2 changes are implemented. As the schema > >sources mentioned by JAXP1.2 schema source property are always > >pre-parsed, > > >- Use XMLGrammarCachingConfiguration to preParse schema sources and the > grammars > would be stored in default pool. > >- Supply this grammar pool to default configuration, as set by the > application > in either of the ways > >* using class name in org.apache.xerces.xni.parser.XMLParserConfiguration > file > in META-INF/services/ > >* using org.apache.xerces.xni.parser.XMLParserConfiguration system > property. > >* Default configuration (StandardParserConfiguration) > > >This pool would be available as part of XMLGrammarPool#retreiveInitialSet > () to > >SchemaValidator component. > > Sounds good to me; is this something you're interested in working on > Neeraj? Once I get the DOMASBuilder/XMLGrammarPoolImpl changes in > (tomorrow with any luck) I'll work seriously on DTD caching; so perhaps the > JAXP stuff would be a good place to jump in if you like. If anyone dont disagree to it , i can start working after you are over with DOM stuff. > BTW, one of the more interesting questions to think about here is what > should happen if the user uses her own grammar Pool implementation in > conjunction with the JAXP property? Right, this was issue for me too. I realized it when i wrote mail yesterday and have asked for clarification. It is not clear to me from the spec , what should be the behavior if for given namespace grammar is already known to parser or supplied as part of initial set by the application ? As concerned people on this issue are busy at JavaOne, i think it would be good idea to wait for while on this issue. As of right now, for any given namespace, grammar provided by user pool implementation would be used against scheamSource property. > Any views on DTD stuff Neeraj? I have nothing new to add here, i am of the same opinion as Andy that internal subset (including ignoring general entity decl to be consistent ) should not affect the decls in the cached grammar. snip from "Subject: Re: priliminary thoughts on DTD grammar caching" : >> "knows" what it's doing. So in the spirit of being 100% conformant, we'd >> probably want to read external decls by default even if it might not make >> much sense in this application. I'd love to hear perspectives on this one! >I say to hell with "the spirit" of conformancy when grammar >caching is employed. Right. And i dont think any application would expect to read grammar all over again when it is supplying one. Another point is what do we get if we do read external decls, if we dont want to modify cached grammar ? Thanks, Neeraj B. Sun Microsystems, inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
