Hi.
> One layer, which is lower, should address the same issue that
> EntityResolver addresses. Namely, to resolve the actual location of the
> file.
>
> I feel that EntityResolver is not quite satisfactory because it is for
> DTD. It takes public id and system id, but public id doesn't make sense
> for other schema languages.
>
> So I suggest
>
> interface GrammarResolver {
> ...
> }
Curt Arnold expects much more information that that. For schema, he needs:
- namespace
- location hints (consider the case of multiple *import* and
*xsi:schemaLocation* for the same namespace
- element/attribute/xsi:type name (if the loading is triggered in the
instance by an element/attribute/xsi:type)
- other attribute name/value pairs (it's possible that the decision of
which grammar location to use depends on a *version* attribute)
So I guess what we really need to pass to *resolveGrammar* method should be
a grammarType (your grammarLanguage) and a GrammarLocationHint interface.
There will be implementations of this interface for different type of
grammars (say, DTDLocationHint and SchemaLocationHint), which will look
very different.
> The second layer, which is at a higher level, addresses the issue of the
> recompilation overhead. That is, achieve higher performance by keeping
> the compiled grammars at some place.
>
> As for this layer, I know I'm just showing my inability, but to me,
Sandy's
> proposal seems to be complicated. It's probably because I can't see why
> such a fine level caching is necessary.
>
> It seems to me that Sandy's interface tries to address this kind of the
> applications, but I think there is no such application.
According to the responses to my original message "[Xerces2] How do we want
Grammar Caching", most people required the flexibility that it's up to the
application to decide which grammar to use when the parser needs one. So I
wouldn't agree with you that "there is no such application".
And remember that, for those simple applications you mentioned, Xerces will
provide default implementation(s) of the grammar caching interface. So
complicated interface doesn't make it more difficult for simple grammar
caching applications.
> To me, it is very natural to compile a schema before I read any XML
> document. So rather than making the parser callback my application, I
> want to specify a grammar to the parser *before* the validation starts.
I think it's natural too (for many applications, or most), and by
implementing the grammar caching interface, you can achieve that. Or,
Xerces can provide such implementation, maybe 15 lines of code.
I've spent some time on the new schema traversal design/coding in Xerces2,
so I was a bit silent about grammar caching lately. Hopefully, I'll have an
updated grammar caching proposal soon, and ask for the opinions from the
community.
Cheers,
Sandy Gao
Software Developer, IBM Canada
(1-416) 448-3255
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
