Where the code that *actually* loads grammars live doesn't sound like a big
problem to me. For example, for XML Schema, we load it in XSDHandler. We
can certainly move all the code to SchemaGrammar if we want. The real
problem is the public interface: how users/applications ask to parse a
grammar.
Two solutions come into mind:
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
of xni, the loadGrammar() methods need to be abstract, and these classes
need getImplementation() methods as well.
Now look at DOM3 DOMASBuilder: it has parseASXXX() methods, which only
takes an input as parameter. I expect it to be changed to take 2
parameters: a String indicating which kind of grammar and an input. Then
look at JAXP's new properties schemaLanguage and schemaSource: they are
also a pair of grammar type and an input. So we have to write code to check
which kind of grammar is requested, then call the appropriate class to load
the grammar. So it seems to me that solution 2 makes more sense: we need it
anyway.
Then what would be this SomeClass? Again we have 2 choices:
1. A new interface/abstract class, which has nothing to do with parser
configuration. (Say, XMLGrammarLoader)
2. An existing parser configuration interface/implementation class.
I wouldn't mind going either way. But XMLGrammarLoader would have many
methods similar to parse configurations: get/set
EntityResolver/ErrorReporter/Property/Feature.
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?
Thanks,
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/05/2002 caching API
11:45 PM
Please respond
to
xerces-j-dev
[EMAIL PROTECTED] wrote:
> [...]
>
> So I believe we have to go with the first approach, because the above
> information is already available in parser configurations.
I'm not convinced that the first approach is the way to go.
Yes, the user will need to set things like the error handler,
entity resolver, and existing grammar cache in the case where
the grammar needs information from other grammars. However, I
don't yet see how this needs methods on the existing parser
configuration interfaces.
> The next question is: which configuration? A new configuration? I always
> thought it's not necessary. Why can't we have a parseGrammar method on
the
> standard configuration? The standard configuration already parses
grammars.
> Now we just expose this functionality by adding a new method.
I'd rather have a new interface (but I wouldn't call it
"configuration").
I personally prefer associating grammar loading with the
grammar classes themselves. The very nature of grammars is
so different that I think it may be hard to come up with
a single generic way to load grammars that works for all
types of grammars.
> We can have a GrammarParser component in the configuration, and make it
an
> internal property. When parseGrammar() is called on the configuration, it
> queries the property, and calls proper method to parse the grammar.
> Validators can also use this property to parse grammars, instead of
calling
> XSDHandler etc. directly.
But what about new grammar types? How will the property
know how to load that? The answer is that it won't unless
the configuration is built with a version of the component
that understands (and knows how to load) those types of
grammars. So... since the user has to control the config
anyway, I'm figuring that it's easier all around to move
the grammar loading outside of the parser configuration
and grammar cache.
--
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]
