On Fri, 12 Apr 2002, Andy Clark wrote:
> [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.
'tis true. and reasonable as an API IMHO.
> > 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.
i think that using this class name even if it doesnt work yet is the right
thing to do. other things in the xerces tree work ( or dont work, in the
sense of being unimplemented ) that way. take ASModel, for example.
> > 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.
*** Really Like This. *** if a user wants to ignore portions of the schema
for some reason then they can implement their own grammar compiler.
one could also make the argument that this would be a *Bad Thing(tm)*
because it would allow people to implement parsers for broken,
noncompliant schemas.
But it's an argument that could be made in either direction on the
'Computer Scientist's Numberline of Ideological Purity' because you are
choosing if you want to be flexible and messy or inflexible and always
correct to the best of your abilities.
> > 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
and this is an interesting point of contention. i *dont* think that this
is an internal only interface. i think that pluggable grammar parsers
will grow in utility once more people get their heads around the idea.
it's also a useful grammar development tool just like being able to pass
parser configurations in on the command line....
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
