Guess I assigned wrong meaning to XMLComponent. :-) There are only two
methods defined on it, to get features/properties. So I thought an
XMLComponent is just an object within a certain environment
(features/properties) and does some certain thing(s); while an
XMLComponentManager is another object that provides such environment. So an
XMLComponent doesn't have to live in a parser configuration, and an
XMLComponentManager doesn't have to be a parser configuration. This was why
I thought the grammar loader and the loader manager have the same
relationship as what XMLComponent and XMLComponentManager have, and should
be derived from them respectively.
But I can certainly live with the idea of not having such derivation, if
XMLComponent is solely for parser configurations.
> parseGrammar(XMLInputSource source, GrammarPool pool):Grammar
We seemed to have agreed to make the grammar pool a public property on the
parser. (Right?) Then I think it's better to treat it the same way here, so
that users don't need to worry whether he's setting the pool on a parser,
or on a grammar loader.
> interface Grammar *
> ...
> * Should this really be called "XMLGrammar"?
I would think. Everything in XNI seems to start with XML.
> And the implementation *might* be something like this:
>
> package org.apache.xerces.util
> class XMLGrammarCache implements XMLGrammarPool,
> XMLComponentManager
I still don't understand why we need this XMLGrammarCache (which is
responsible for loading different kind of grammars) to implement
XMLGrammarPool. When a user wants to preparse a grammar, he would simply
want to
XMLGrammar grammar = someObject.loadGrammar(input);
But grammar loaders are deep in the impl package, and are not intended to
be used directly, so we introduce a util class so that the user can
XMLGrammarSOMETHING loader = new XMLGrammarSOMETHING();
XMLGrammar grammar = loader.loadGrammar
("http://www.w3.org/2001/XMLSchema";, input);
I don't see why XMLGrammarSOMETHING needs to implement XMLGrammarPool. Of
course a grammar pool is useful, but it can always be passed to the loader
by setting a property.
> > 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.
Aren't constructors for initialization purposes? I think giving an object
the initial state *should* happen in the constructor. The state of this
util class is a list of grammar loaders, and the constructor sets it to the
initial state: putting two loaders in the list. I don't see why it's not
proper.
> I don't why it requires the grammar cache to be a component
> and a component manager.
It needs to be a component because it needs to know about the features and
properties (and forward them to grammar loaders). It needs to be a
component manager because I thought it should implement XMLComponentManager
(to manager grammar loaders), which, of course, is not a must now.
As I said in the previous note, this is one way of how validators can load
grammars: using the XMLGrammarSOMETHING#loadGrammar(type, input) method.
This requires XMLGrammarSOMETHING to be a property, so that validators can
query it. But I don't think it should be the grammar pool property, but a
new one.
Another way is to use the loaders directly, because each validator knows
which loader to use. Then the validators would be responsible for
forwarding features/properties to the loaders, or the loaders can implement
XMLComponent, so that they can be updated by the configuration. But I don't
see how a validator can add an component to the configuration.
Cheers,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
