Kohsuke KAWAGUCHI wrote:
> As I wrote in the other mail, I think that the pool is really
> unnecessary.

Are you saying that the pool interface, as suggested, is
not sufficient? Or are you saying that you don't see a 
need for grammar caching? If it's the latter, then I find
this comment extremely short-sighted. 

For three years we have received requests from users to be 
able to cache grammars. Just because you don't see a need 
for a grammar cache does not mean that there is not a serious 
need. (You might remember the thread on xml-dev where Elliotte 
Rusty Harold claimed that there was no need for updating XML 
for Unicode 3.1 because non-English speakers could always use 
English for element and attribute names. Just because he 
doesn't see the need for it, doesn't mean that there isn't 
one.)

People writing business applications that run on a server
and receive documents from business partners need grammar
caching for several reasons. First: performance. They are
processing 1000s of XML transactions per second (or would
like to) and cannot afford to re-parse and re-compile the
grammar for each instance document. Second: validation. If
an instance document arrives and is supposed to conform to
a specific grammar, should that document be allowed to
reference a different grammar? or override declarations by
using the internal subset? No way, Jose. This kind of 
grammar "spoofing" cannot be allowed in the business
application.

In this area, I would rather take the suggestion from users
that are developing real-world business applications. And
they have been telling us that they need this feature. We
have been listening but, so far, have not had the infra-
structure in the parser to support it. So that's why we
are developing the new validation engine with grammar
caching in mind.

> I'd appreciate if you would show me a case where a namespace-level 
> cache is necessary.

Going from the assumption that grammar caching is needed,
how else would you locate a grammar that is defined with
a target namespace?

-- 
Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to