[EMAIL PROTECTED] wrote:
>
> Basically, when the parser validates a document instance, there are two
> sets of grammars. The first set is store inside the parser (we can call it
> the local set), which contains grammars available to the current parsing
> (the current document); while the second set is under the application's
> control, used to store cached grammars (we can call it the cached set). The
> second set is not mandatory, because some applications might not be
> interested in grammar caching at all.
A good grammar caching overview.
> I don't think we should *always* ask the application for grammars. Please
> refer to Curt's message, and my reply.
Of cource, I did not expressed well.
> This is certainly a clean design, but I guess many Xerces1 users are used
> to using EntityResolver to override grammar locations, and such change
> would make them unhappy :-)
Are they happy with current solution? Besides it should be also addressed
in other API such as SAX as well.
> > > 3. There is still a problem for the design of schema caching. Assume
> > > grammar A (that is, a grammar with target namespace A) is known to the
> > > parser, then the parser asks the application for grammar B. The
> application
> > > returns grammar B, which imports a different grammar A. Now the two A's
> > > conflict (we assumed a one-grammar-per-namespace rule). To avoid such
> > > confliction, in the GrammarResolver interface, we ask the application
> to
> > > provide a different grammar B in this case (method grammarConflict()).
> >
> > I assume that cached grammar B just references grammar A. So
> > parser can use its A copy.
>
> Because the parser has no control over how cached grammars are stored, it's
> possible that the application returns two different A's.
But the application is asked for A just once, is not it? It cannot return
two A's for current document.
> > Here I doubt if I understand it. Why parser does not interact
> > with pool directly? I prefer to call it GrammarCache.
>
> What I called grammar pool is a abstract concept. It refers to a collection
> of grammars. The application can choose whatever way to manage it. While
> the interface GrammarResolver/GrammarCache is used to communicate between
> the parser and the application. So the parser only interacts with such
> interface, not the physical collection of grammars.
Yes, I used for the decoupling the Key that is under application
control. It also allows a Map implementation of the cache.
> > public interface GrammarCache {
> > // it can be implemented by a Map
> > public Grammar get(Key);
> > public Grammar put(Key, Grammar);
> > public interface Key {
> > }
> > }
> >
> > public interface CacheKeyFactory {
> > //GrammarCache.Key createKey(String namespace);
> > //GrammarCache.Key createKey(String pID, String sID);
> > GrammarCache.Key createKey(String grammarType,
> > String grammarKey,
> > String hint);
> > }
> >
> > public interface GrammarResolver {
> > // ask the application to override import
> > // schemaLocation.
> > public XMLInputSource resolveGrammarLocation(String grammarType,
> > String grammarKey,
> > String hint);
> > // ask the application to override include/redefine
> > // schemaLocation.
> > public XMLInputSource resolveGrammarLocation(String grammarType,
> > String hint);
> > }
>
> We still need to decide whether to have one GrammarResolver interface, or
> two interfaces GrammarCache/GrammarResolver. What do others think?
>
> Other than that, your interfaces don't look too much different from my
> GrammarResolver. But other methods in my GrammarResolver have their reason
> to be there. Please refer to my message replying Curt.
The crossposting is really bad habit :-).
I think that we can get rid of getInitalGrammarSet() and returnFinalGrammarSet()
if whole cache will look as a Map.
Why grammarConflict()? Cache simply must return grammar of proper type
for proper namespace. Why to negotiate it.
> > Time diagram from parser point of view:
> >
> > $key = ask CacheKeyFactory for a key
> > $grm = ask GrammarCache for Grammar
> > if $grm == null {
> > $in ask GrammarResolver for InputSource
> > $grm = constructGrammar($in)
> > put $grm into cache under $key
> > }
>
> I basically agree. But as the first step, we should try to look for the
> grammar in the local grammar set. If the grammar is not there, we turn to
Right.
> ask the application. And for the last step, instead of put the grammar into
> cache, we should first store it in the local grammar set, then return the
> grammar to the application. It's up to the application to decide whether a
> grammar should be cached.
The put() is implemented by GrammarCache i.e. application. So it can decide.
Cc.
--
<address>
<a href="mailto:[EMAIL PROTECTED]";>Petr Kuzel</a>, Sun Microsystems
: <a href="http://www.sun.com/forte/ffj/ie/";>Forte Tools</a>
: XML and <a href="http://jini.netbeans.org/";>Jini</a> modules</address>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
