> I don't think so. The xni.grammars package is for abstracting
> grammar representations and associated grammar functionity like
> caching. Meanwhile, specific grammar types and their associated
> validation component(s) are implementation dependent.
We are talking about public interface here, right? Are you saying that the
user should call DTDGrammar.loadGrammar() or SchemaGrammar.loadGrammar()
directly (where the two classes are down inside xerces.impl package). Isn't
a software package supposed to be divided into interface and
implementation, and the user should only interact with the interface part?
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]
Andy Clark
<andyc@apache. To: [EMAIL PROTECTED]
org> cc:
Subject: Re: integrating grammar
preparsing with the grammar
04/09/2002 caching API
02:40 AM
Please respond
to
xerces-j-dev
[EMAIL PROTECTED] wrote:
> 1. XXXGrammar#loadGrammar(input)
> 2. SomeClass#loadGrammar(grammarType, input)
>
> Solution 1 means we need to have a bunch of abstract classes for all
kinds
> of grammars, put them in xni.grammars package, and define static
> loadGrammar() methods on them. But since Xerces2 is just an
implementation
I don't think so. The xni.grammars package is for abstracting
grammar representations and associated grammar functionity like
caching. Meanwhile, specific grammar types and their associated
validation component(s) are implementation dependent. I don't
think we should be in the business of mandating (by defining
XNI interfaces) what grammars are available and how they are
to be loaded, except in a generic way.
In short, I don't see any problem with the first solution. And
since you can't have a grammar class without its validator
implementation, I think it would map just as easily to the
other APIs that you refer to later in your message.
> I wouldn't mind going either way. But XMLGrammarLoader would have many
> methods similar to parse configurations: get/set
> EntityResolver/ErrorReporter/Property/Feature.
I don't mind the duplication of methods if the interface
approach makes sense.
> BTW, (at the level of XNI, not SAX or DOM or JAXP) is GrammarPool as
> important as EntityResolver? If the answer is yes, should we have
> set/getGrammarPool methods on parser configurations?
No!
I do not want to require validation of any kind directly
in the core and parser framework. This stuff can just as
easily be layered or separate.
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
