[EMAIL PROTECTED] wrote:
> Note that in Xerces implementation, error handler, entity resolver, and
> grammar pool are all properties, so we can ignore this set of methods. Now
> we can see how similar this interface is to XMLComponent. Let's keep this
> in mind.
I don't like where you're headed with this. There's no reason
for this grammar loader interface to extend XMLComponent. The
component interface is for configurable components within a
parser configuration. And the parser configuration framework
exists because there are different things generated as output
(e.g. DOM tree or SAX events). However, in the case of loading
grammars, there's only one kind of output, a Grammar object.
There may be different ways to create that grammar but there's
still only one output. Therefore, there's no need for using
XMLComponent or other interfaces for the loading implementation
of a specific grammar type. We just need to define the interface
by which the loading of the grammar is initiated as well as how
to cache these grammars.
Having said that, we need to remember that we're also talking
about how we will implement this for use within Xerces. We can
do any number of things for convenience but there's no reason
to add things to the general interfaces that is an implementation
detail.
> Then how will the users use the loader classes? The implementation classes
> are deep inside the impl package, and we shouldn't ask/encourage the users
> to call them directly. An idea would be to provide a class (possibly in
> xerces.parser package), which has a loadGrammar(grammarType, input) method.
> This maps to Andy's XMLGrammarCache class. But I don't like the idea that
> it implements XMLGrammarPool. I think the relationship between grammar pool
This is just a utility implementation class that is used
within our parser implementations. I was just suggesting one
way we could implement it but there other ways of doing it,
obviously. My idea for implementing the grammar pool is not
part of the xni.grammars package.
I probably confused you because I was talking about both the
interfaces and the implementation class that would implement
those interfaces for use within the parsers.
> I'd like to see that the grammar pool is passed to grammar loader as a
> property. (This is how we implemented the schema grammar loader.) Let's
Good point. I'm sorry I overlooked this. So replace the
following method:
parseGrammar(XMLInputSource source):Grammar
with:
parseGrammar(XMLInputSource source, GrammarPool pool):Grammar
> interface XMLGrammarLoader extends XMLComponent {
> public Grammar loadGrammar(XMLInputSource) throws ...;
> }
>
> class XMLGrammarCache implements XMLComponentManager {
> public void setFeature(...) throws ...;
> public void setProperty(...) throws ...;
> public XMLEntityResolver getEntityResolver();
> public void setEntityResolver(...);
> public XMLErrorHandler getErrorHandler();
> public void setErrorHandler(...);
> public Grammar loadGrammar(String, XMLInputSource) throws ...;
> public void addGrammarLoader(String, XMLGrammarLoader) throws ...;
> }
I understand what you're trying to do here but I just don't
like the way that it's done. You're using implementation
details to drive the design of the interfaces. If we took
this approach with the parser pipeline, then the handler
interfaces would extend XMLComponent as well. But we don't
require anyone to use the component architecture -- that's
to ease specific implementations.
Therefore, our implementation of the grammar cache *can*
implement component manager. I don't have a problem with
that. But the clarification I have is that our grammar
loader *implementations* may implement XMLComponent but
this does not mean that all grammar loaders need to. Does
this make sense?
To rehash, here's an example of what the design *could*
look like:
package org.apache.xerces.xni.grammars
interface Grammar *
interface XMLGrammarDescription
interface XMLGrammarPool
interface XMLGrammarLoader
* Should this really be called "XMLGrammar"?
And the implementation *might* be something like this:
package org.apache.xerces.util
class XMLGrammarCache implements XMLGrammarPool,
XMLComponentManager
package org.apache.xerces.impl.dtd
class DTDGrammarLoader implements XMLGrammarLoader,
XMLComponent
But I don't think that implementing the component and
component manager interfaces is strictly required for
grammar loading.
> The constructor of XMLGrammarCache can register loaders for DTD and schema
I try not to use constructors to set state for objects
unless those objects are immutable.
But you're right in that the configuration would register
the appropriate grammar loaders with the grammar cache
instance used by that configuration. This is assuming that
our grammar cache implementation also adds convenience
method(s) for loading the grammars that are stored in the
pool.
> The last question is how the validators (in the parser pipeline) load
> grammars. One way of doing it is to make XMLGrammarCache a
> component/property of the parser. The configuration creates/registers it,
> and validators query/use it. Of course, this requires XMLGrammarCache to be
> both a component, and a component manager. Another approach is not to use
> XMLGrammarCache in the configuration, but each validator uses the proper
> loader class directly. I don't have a preference here.
I don't why it requires the grammar cache to be a component
and a component manager. A property in the configuration does
not have to implement the XMLComponent interface or any other
interface for that matter (e.g. SymbolTable). And it's the
configuration's job to keep track of settings -- there should
not be other components that do the same thing within the
configuration.
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
