Hi Andy,
> Let me rehash your options as one-liners:
And an excellent rehash it was too. :-) Just some comments on your
XMLGrammarParser proposal:
> 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
representations that xerces (a parser!) can use for its own purposes. So
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?
> parseGrammar(XMLInputSource source):Grammar
> throws IOException, XNIException
[snip]
> class XMLGrammarCache implements XMLGrammarPool
[snipping more Configuration/parser-style methods]
> loadGrammar(String,XMLInputSource) throws IOException,
> XNIException
>We could even implement this class generically so that
>grammar parsers are "installed" in much the same way that
>message providers are installed on the error reporter
>component. This way, the standard parser configuration
>would install parsers for DTDs and XML Schemas but other
>people can re-use the grammar cache impl when they make
>new configurations with the grammar/validator(s) of
>their choice.
So we'd want to add a
addGrammarCompiler(XMLGrammarCompiler)
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.
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
least there's the potential for the rest of the components in the
xni.grammars package either to be used by real users or even implemented by
them. I'd rather see us define an interface with a parseGrammar(String,
XMLInputSource) method, implement it somewhere and invite other folks to
implement it differently/better if that grabs their fancy. Our
implementation can worry about loading grammars with the infrastructure we
have, and other people can extend that with their grammars when those
emerge.
But I could certainly live with this approach; it's more extensible than
what we have now if nothing else.
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]
