[EMAIL PROTECTED] wrote: > That's certainly a thought, so long as we're ready for the > onslaught of bogus bug reports... So do you have an updated forecast regarding when you think you'll be done? or close enough to warrant a new beta release? > >> - modify xni.parsers.XMLEntityResolver and impl.validation.GrammarPool > >> and/or add some new XNI classes to reflect the Grammar caching discussion > > >I don't like this one. I would like to keep XNI as only > >the streaming infoset and parser construction pieces. > > But you've already got an XMLEntityResolver in the xni.parsers directory. > If we want this class to be optimally useful, then it makes sense to change > it so that it's good for more than DTD location, IMHO. This would seem to > involve passing some kind of LocationHint interface to its ResolveEntity > method, as Sandy/Petr/Curt were discussing. What threads were these discussions in? I can't seem to find them now. Until I can review the discussion, I'm still not convinced that the XMLEntityResolver needs to be modified. > Validation is already contemplated in the pipeline and we've got to provide > some standardized, general way for validators to find their food. We have a generic mechanism for that -- we don't need to modify XNI to provide an additional mechanism for something that is implementation dependent. > I think it would be useful to have some kind of really general (empty?) > Grammar interface simply so that GrammarPools (or GrammarResolvers or > whatever we call them) have something other than Object to return. But I But that doesn't need to be in XNI for it to be defined and used by the Xerces2 reference implementation. > Wouldn't we rather have a StandardSchemaParserConfiguration extending > StandardParserConfiguration or something like that? Just a thought. The number of configurations possible is exponential. However, let's concentrate on providing a skeleton configuration and the typical configuration used by 90% of the people out there. I am still interested in an XML file that would define a configuration. Then we could write a tool that generates the code for the configuration (so that we don't have to have an XML parser to create an XML parser at runtime). In this way, we could even change what the "standard" configuration is based on a build option in Ant. [Ted, I thought you were looking at this. Any progress to report?] -- Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
