grammar preparsing API: some options

[ne...@ca.ibm.com]

Hi folks,

Here's my attempt to get some consensus viz. moving forward on some kind of
grammar preparsing API.  By grammar preparsing API, all I mean is one
(parse|load)Grammar(...):  Grammar methods accepting an XMLInputSource and
probably a String corresponding to the URI of the kind of grammar to be
resolved.  Perhaps we'll want another one taking a  XMLGrammarDescription
as a parameter, perhaps not.

Here's the choices as I grasp them:

(a) Not have one.  Just provide such a method on one or more of our own
Configurations in the parsers package, or maybe static methods on the
various Grammar implementations, and tell the world to use that.

(b) Write a new interface, extending xni.parsers.XMLParserConfiguration, in
the xni.grammars package; adding this (parse|load)Grammar method to this
new interface.  Configurations interested in supporting preparsing of
grammars they understand can then implement this new interface--in addition
to whichever ones they already implement--for the grammars they understand.

(c) Add the method to the existing xni.grammars.Grammar interface.  This
would turn Grammar into a factory of instances of itself, but would at
least give a grammar-implementation-independent way of preparsing grammars.

(d)  Make a new interface in the xni.grammars package, perhaps called
XMLGrammarCache, whose sole function is grammar preparsing and which
extends nothing.

(e)  Add grammar preparsing onto XMLGrammarPool, under the assumption that
in any real-world case in option (d), the same object would serve both for
preparsing and storage.

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.  :-)

My own preferences would be (b) then (e) then (d).  I don't like the other
two much at all.

Have I missed any options?  If not I'll keep track of any votes and let the
list know what's happened by end of week (or earlier if people stop
responding.  :-).

Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone:  905-413-3519, T/L 969-3519
E-mail:  neilg@ca.ibm.com



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Re: grammar preparsing API: some options

[Andy Clark <an...@apache.org>]

neilg@ca.ibm.com 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 * andyc@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org