[EMAIL PROTECTED] wrote: > 1. XXXGrammar#loadGrammar(input) > 2. SomeClass#loadGrammar(grammarType, input) > > Solution 1 means we need to have a bunch of abstract classes for all kinds > of grammars, put them in xni.grammars package, and define static > loadGrammar() methods on them. But since Xerces2 is just an implementation
I don't think so. The xni.grammars package is for abstracting grammar representations and associated grammar functionity like caching. Meanwhile, specific grammar types and their associated validation component(s) are implementation dependent. I don't think we should be in the business of mandating (by defining XNI interfaces) what grammars are available and how they are to be loaded, except in a generic way. In short, I don't see any problem with the first solution. And since you can't have a grammar class without its validator implementation, I think it would map just as easily to the other APIs that you refer to later in your message. > I wouldn't mind going either way. But XMLGrammarLoader would have many > methods similar to parse configurations: get/set > EntityResolver/ErrorReporter/Property/Feature. I don't mind the duplication of methods if the interface approach makes sense. > BTW, (at the level of XNI, not SAX or DOM or JAXP) is GrammarPool as > important as EntityResolver? If the answer is yes, should we have > set/getGrammarPool methods on parser configurations? No! I do not want to require validation of any kind directly in the core and parser framework. This stuff can just as easily be layered or separate. -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
