[EMAIL PROTECTED] wrote: > > interface XMLGrammarParser > > I'm not sure I like this name; I think "parser" implies to the XML world an > object that you use to gain access to the contents of something, as opposed > to an object that transforms things from XML representations into
Yes, but it's "parsing" the grammar's native format from a stream. That's why I chose that name. > until we get around to defining--or implementing--API's to let people get > access to grammar contents the name's a real misnomer. How about > XMLGrammarCompiler? And then what? Once we define (or implement) an API to access the grammar contents, are we gonna change the name back to XMLGrammarParser? Why not skip the hassle and name it that from the beginning with the intent that we will be defining (or implementing) some API in the near future. > So we'd want to add a > > addGrammarCompiler(XMLGrammarCompiler) That was my intention even if I didn't put the method in my example interface definition. > method on to this class. This would also give the XMLGrammarCompiler > interface a purpose in life--otherwise classes would implement it but it > would be required nowhere. Yep. > I think my biggest problem with this approach is that it isn't an API--it's > an implementation that we invite people to use that sort of makes use of an > internal API that only writers of grammar components will ever need. At I understand your concern. It's just that I want to stay away from defining a JAXP-like factory for XNI at the moment. -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
