Hi Neeraj,



>> - XMLGrammarPool should be made into an external property.  This
>>   should be read-only within a parse, but if an application wants to
>>   change it between parses it would be caveat emptor.  It's
>>   conceivable this could be useful, so no point in preventing it.

>          We will add the flexibility to whole grammar caching mechanism
by making
XMLGrammarPool as external property, it would be recognized by different
configurations and validator components.

Well that's one of the first discoveries I made:  You can happily set a
grammar pool implementation today via setProperty(...) on any configuration
that understands GrammarPools, and it'll work fine.  i.e., it's as external
as it's going to get.  I haven't looked at fixing its  value during a parse
though; if someone else wants to do that it would be cool.

I've got grammar locking working locally though, and I'm well on the way
towards cleaning up DOMASBuilder.

>We can also change the way JAXP1.2 changes are implemented. As the schema
>sources mentioned by JAXP1.2 schema source property are always
>pre-parsed,

>- Use XMLGrammarCachingConfiguration to preParse schema sources and the
grammars
would be stored in default pool.
>- Supply this grammar pool to default configuration, as set by the
application
in either of the ways
>* using class name in org.apache.xerces.xni.parser.XMLParserConfiguration
file
in META-INF/services/
>* using org.apache.xerces.xni.parser.XMLParserConfiguration system
property.
>* Default configuration (StandardParserConfiguration)

>This pool would be available as part of XMLGrammarPool#retreiveInitialSet
() to
>SchemaValidator component.

Sounds good to me; is this something you're interested in working on
Neeraj?  Once I get the DOMASBuilder/XMLGrammarPoolImpl changes in
(tomorrow with any luck) I'll work seriously on DTD caching; so perhaps the
JAXP stuff would be a good place to jump in if you like.

BTW, one of the more interesting questions to think about here is what
should happen if the user uses her own grammar Pool implementation in
conjunction with the JAXP property?  Should it be responsible for storing
the preparsed grammars, or should the parser have a "wrapper"
implementation that stores them regardless what the user's implementation
does?

>That reminds me part of code that has been commented in
StadardparserConfiguration (l358-363) when no grammar pool has been
specified by
the application.
>          When this is the case, we can have do nothing XMLGrammarPool
implementation, dont cache any grammar and dont provide any grammars as
part of
initialGrammarSet.

null sounds good to me here.  :-)  null checks are always at least as
inexpensive as method calls, usually cheaper I'd think, so I'd prefer to
have no object at all than some sort of do-nothing object.

Any views on DTD stuff Neeraj?

Cheers,
Neil




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

Reply via email to