[EMAIL PROTECTED] wrote:
> [...]
Let me rehash your options as one-liners:
(a) Convenience methods on configuration impl and/or grammar impl.
(b) Extend parser config interface to add grammar loading methods.
(c) Add method to grammar interface.
(d) Create new grammar cache interface.
(e) Make grammar pool do both loading and caching.
> Note we haven't addressed the question as to what the parseGrammar method
> should do when presented with a grammar type it doesn't understand; my
> thought would be to throw an XMLConfigurationException but Andy probably
> has a different view. :-)
Am I that transparent? ;) Yes, I do have a different view. The
configuration exception doesn't make sense for this purpose.
> My own preferences would be (b) then (e) then (d). I don't like the other
> two much at all.
I hate (b); I don't like (c); and (e) doesn't seem appropriate
because caching is not the only reason to parse grammars. A
user may want to parse a grammar to investigate its content
models, etc. without caching or validating anything.
It's true that at the moment we haven't defined how a person
would generically access the contents of a DTD, XML Schema, or
other kind of grammar. But there's nothing preventing us from
doing that in the future (perhaps in xni.grammars.dtd and
xni.grammars.xs packages???). This is just like the situation
where grammar caching was an implementation detail until we
understood their usage enough to design appropriate interfaces.
I like (d) the most but I wouldn't call it XMLGrammarCache
-- otherwise, what's the difference with (e)? And I wouldn't
append "Configuration" either because I don't see any reason
for grammar parsing pipelines.
How about just "XMLGrammarParser"? It would share many of
the same methods as the XMLParserConfiguration -- but this
does *not* mean we should extend that interface as suggested
by choice (b).
interface XMLGrammarParser
setFeature(String,boolean) throws XMLConfigurationException
getFeature(String):boolean throws XMLConfigurationException
setProperty(String,Object) throws XMLConfigurationException
getProperty(String):Object throws XMLConfigurationException
setLocale(Locale)
getLocale():Locale
setErrorHandler(XMLErrorHandler)
getErrorHandler():XMLErrorHandler
setEntityResolver(XMLEntityResolver)
getEntityResolver():XMLEntityResolver
parseGrammar(XMLInputSource source):Grammar
throws IOException, XNIException
Following this approach, we would *not* put parseGrammar
methods on the grammar implementations themselves but would
rather have a separate parser class for those grammar impls.
For example, we would have the "DTDGrammar" and its
corresponding "DTDGrammarParser" which would implement the
XMLGrammarParser interface.
The next thing is that we would probably want to have a
grammar cache implementation that would have a method to
load grammars of different types. Notice the difference in
that its "parseGrammar" method takes a String parameter
for the grammar type:
class XMLGrammarCache implements XMLGrammarPool
setFeature(String,boolean) throws XMLConfigurationException
getFeature(String):boolean throws XMLConfigurationException
setProperty(String,Object) throws XMLConfigurationException
getProperty(String):Object throws XMLConfigurationException
setLocale(Locale)
getLocale():Locale
setErrorHandler(XMLErrorHandler)
getErrorHandler():XMLErrorHandler
setEntityResolver(XMLEntityResolver)
getEntityResolver():XMLEntityResolver
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.
Suddenly my head hurts... I hope this makes sense and/or
seems like a reasonable solution.
Comments?
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
