> I was actually suggesting that
> the validator components would only rely on the grammar
> cache being in the configuration. But it would be the
> parser configuration's responsibility to create the cache,
> add a loader for each type of grammar used in that config,
> and then adding the cache as a property.
I just realized that there might be problems if the validators don't
interact with grammar loaders directly. When the schema validator wants to
load a schema grammar, it wants the loader to know not only those grammars
available in the grammar pool/cache, but also those that are known to the
validator.
For example, the instance document has xsi:schemaLocation="A a.xsd B
b.xsd". After grammar A is loaded, the validator calls the loader to load
grammar B. If b.xsd imports namespace A, we want the already-loaded A to be
used, instead of loading A again. So we need a way to make grammar A
available to the loader, which is why currently we pass an XSGrammarBucket
(which contains grammars known to the validator) to XSDHandler's
constructor.
One may suggest that we store grammar A in the pool/cache after it's
loaded. But remember that the pool/cache should be maintained by the
application, who might not want to cache A at all.
Cheers,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]
Andy Clark
<andyc@apache. To: [EMAIL PROTECTED]
org> cc:
Subject: Re: grammar preparsing API:
some options
04/19/2002
10:17 PM
Please respond
to
xerces-j-dev
[EMAIL PROTECTED] wrote:
> 1. Where does loadGrammar(type, input) method live?
>
> [...]
>
> This is why I think a util class with (only) this method is necessary.
For
> the kind of requirements Andy mentioned, people can easily preload a
> grammar using this util class, then store it in a grammar pool
> implementation.
There's nothing preventing us from writing such a utility
class and then having the grammar cache implementation use
that utility class internally when someone calls the
"loadGrammar" method on XMLGrammarCache.
> 2. Initialize the object that has loadGrammar(type, input) method
>
> Currently Xerces supports 2 kinds of grammars: DTD and XML Schema, so
> people would expect to be able to load these two kinds of grammars using
> some object that has a loadGrammar(type, input) method (because, again,
> users shouldn't use classes in impl package directly). If such object
> doesn't live within a parser configuration (it won't if people just want
to
> load a grammar and analyze it), then it doesn't have a chance to know
> loaders for DTD and schema.
The reason why I don't like this approach is the following:
if someone doesn't care about one of the types of grammars
(e.g. they don't need XML Schema) but we tell them that
they should use the utility class, then they now have to
drag along all of the XML Schema stuff.
I'm always striving for a completely layered approach so
that we don't make everything depend on everything else.
So pre-loading a utility class with loaders for DTDs and
XML Schemas is well-intentioned and convenient but would
then require a large dependency in the case where the
user doesn't care about certain types of grammars.
> 3. How validators load grammars
>
> Andy, from your message, I got the following impression. Correct me if
I'm
> wrong.
>
> When the parser configuration creates various validators, it creates a
> bunch of grammar loaders accordingly, and stores them as different
> properties. Each validator will then query the proper property to get the
> grammar loader, and call loadGrammar(input) on it. The grammar loaders
also
> implement XMLComponent interface, so that they'll be aware of any
> feature/property settings.
I wasn't suggesting that. I was actually suggesting that
the validator components would only rely on the grammar
cache being in the configuration. But it would be the
parser configuration's responsibility to create the cache,
add a loader for each type of grammar used in that config,
and then adding the cache as a property.
--
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]
