Hi Andy,
Nice to see we've got some company on this topic! I'll just respond to
this long message you sent in response to one of mine, then I'll send
something to try to get some consensus on how to proceed--after all,
discussion is only as good as what finally results from it...
>> That's also why I wouldn't mind seeing methods like lockGrammarPool and
co.
>> on the configuration. People (Joe Kesselman for instance) have
complained
>> that even requiring users to know about configurations is bad; if we can
>These methods don't make sense for the configuration interface
>because it promises that *all* configurations will have grammar
>caching functionality. This is clearly not the case.
Sorry if I was unclear; I meant on the grammarCachingConfiguration
interface that was then my most-favoured approach to a generic means of
grammar preparsing. I'm happy to see these only on the grammar pool
however.
>The Xerces Native Interface is called such because it is native
>to the *internals* of the parser.
Really--is that all? I thought our implementation was merely the
*reference* implementation of XNI, and that anyone who needs to do
event-based XML programming but needs to go beyond SAX for whatever reason
was herewith invited to use XNI. Maybe not average users but this
conception--which certainly pervades our XNI docs--certainly places XNI at
a higher level than a method by which our proprietary components talk to
one another...
>Let's make a convenient grammar caching implementation for
>people to use with the parser configuration implementations
>that we provide and design the internal APIs appropriately.
I suggest we design API's that meet the real need that caused us to go down
this path, and then implement them. Obviously how difficult the
implementation is, and what other API's like DOM and JAXP are doing, and
how to fit this in with the basic XNI framework will all substantially
influence us; but, like all other XNI discussions I've seen save this one,
it should be more than an internal API we're talking about here.
>But what about Relax NG or other types of grammars? This
>becomes tricky because there's no point in being able to load
>a grammar of a specific type if the configuration doesn't have
>a validator in the pipeline that can handle that kind of
>grammar. To solve this problem...
Or whatever configuration implementation implements this grammar
configuration would have to implement the right kind of pipeline.
Obviously our default implementation will have to do this; i.e., if a user
wants DTD grammar caching and no schema support in the parser, seems
inevitable to me that they're going to have to implement their own methods
for grammar preparsing, just to take out references to schema.
> GrammarCache cache = new GrammarCache();
> DTDGrammar[] dtds = {
> DTDGrammar.load("http://example.com/grammar1.dtd";),
> DTDGrammar.load("http://example.com/grammar2.dtd";),
> };
> cache.cacheGrammars("DTD", dtds);
[snip]
> XMLParserConfiguration config = new MyConfig(cache);
> DOMParser parser = new DOMParser(config);
This code segment seems to imply that the GrammarCache and the grammar pool
implementation are done by the same object. If this is expected to be true
in general, perhaps grammar preparsing function should live directly on
XMLGrammarPool?
Anyway there's some random responses; next e-mail I'll try and put a list
of options together that it seems to me have been floated during this
thread.
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
