Hi Neil,
 
> 1.  Given that we already have the EntityResolver interface, which is
> optimized for DTD's, I think having some kind of externalDTDLocation
> property would just muddy the issue.  

If i was not clear, actually,  I was talking only about case a) 
"" used in the case where the document contains no DOCTYPE line.""
                EntityResolver wont be useful in the case when document contains 
no DOCTYPE declaration. As resolveEntity is called when external entities are 
referenced.
        First of all, i see this, we are providing a *functionality*, that all 
those instance documents which do not have DOCTYPE declaration would be able to 
*validate*  against DTD Grammar, which is not possible now. It doesn't matter 
that grammar is already cached (except for performace reason, obviously :-) ) or 
that grammar is built by telling parser about the location. 
        Now this is important functionality we can provide, and we see lots of 
queries on it,  so i was suggesting if we choose to provide this functionality 
this should not be speciality of only one configuration, not only against cached 
grammar.

> So what piece of the coding do you want to help out with Neeraj?  :-)
 
As pavani is looking into XMLGrammarPoolImpl, i can start working either on 
SchemaValiadator or DOMAsBuilder.  Will u be modifying Grammar and 
XMLGrammarDescription  interfaces , if there isn't any objection :-)


Regards,
 
Neeraj B.
Sun Microsystems, inc.

 
> Neeraj Bajaj <[EMAIL PROTECTED]> on 02/07/2002 10:37:35 AM
> 
> Please respond to [EMAIL PROTECTED]
> 
> To:   [EMAIL PROTECTED]
> cc:
> Subject:  Re: grammar caching requirements
> 
> 
> > Andy Clark wrote:-
> > So I think we *should* keep this information linked: grammars
> > and grammar descriptions. Perhaps something like the following:
> >
> >   public interface Grammar {
> >     public XMLGrammarDescription getGrammarDescription();
> >   }
> >
> >   public interface XMLGrammarDescription
> >     extends XMLResourceIdentifier {
> >     public String getGrammarType();
> >   }
> >
> > The XMLGrammarPool interface would stay the same.
> 
> >I think that it would be simpler in the end to keep the grammar
> >description information with the grammar.
> 
> > If a grammar doesn't keep a copy of its associated grammar
> > description then each grammar pool instance needs to have
> > all of the logic to determine if a requested grammar
> > description properly identifies a registered grammar.
> >
> > Does this make sense?
> 
> it makes sense :) it is more usable and extensible than a grammar object
> keeping
> information about its type only. I feel it keeps our options open to add
> more
> things that we may find are required to identify (other) grammars in
> future.
> 
>            We need constants for different kind of grammars which help
> validaton
> components and grammar pool to identify what kind of grammars they are
> interacting. we should shift the two constants defined for each grammar
> type to
> XMLGrammarDescription.
> 
> public interface XMLGrammarDescription
>      extends XMLResourceIdentifier {
> 
>     public static final String XML_SCHEMA = "XSD";
>     public static final String XML_DTD = "DTD";
> 
>      public String getGrammarType();
>    }
> 
> > > 3.  It should encompass both XML Schemas and DTD's;
> >
> > And more...
> >
> > > 4.  It should permit grammars to be preparsed or cached as they are
> > >     encountered while validating instance documents;
> > > 5.  It should permit the application to "lock" the cache, that is,
> > >     prevent any more grammars from being added.
> >
> > And we need to be able to allow a DTD grammar to a) be
> > used in the case where the document contains no DOCTYPE
> > line.
> 
> I am of the opinion that we should keep these things away from this
> configuration. I see this configuration as responsible for caching and
> making
> the grammar available to parser before hand, though it can always be
> extended
> if required.
>                      Moreover, i think this is a feature which is not
> limited to this
> configuration and we should provide this by some other means something like
> 
> external-schema-location we have for schema grammar.
> 
> > b) override the grammar specified in the DOCTYPE declaration.
> 
> If grammar with the same root element is already available to the parser,
> as a
> part of initial grammar set provided by the application before validation
> begins. Will parser still ask application for the grammar ? IMO, it should
> not.
> I consider this as something which application knowingly and intentionally
> telling to the parser to validate instances with. If its not available with
> the
> parser then it should give chance to application to provide it from its
> cache.
> But i think it definitely requires more thought. I feel same would hold
> true for
> schema ???
> 
>            I think many applications would like to preparse all the
> grammars and
> provide it as as initial set to the parser before parsing begins.
> Applications
> would like to provide their own implementation by setting the grammar pool
> property. We can make it easy for the application by introducing a method
> in
> XMLGrammarPoolImpl, making it more reusable, which allows set of grammars
> to be
> incorporated in its data structures thus making it available to the parser
> as
> part of initial grammar set.
> 
> Regards,
> 
> Neeraj B.
> Sun Microsystems, inc.
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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]
> 







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

Reply via email to