Hi Andy, > Really? I've been busy on other projects lately and didn't know you were making such great progress! :) Once we clean up the packaging, should we do another beta release with preliminary Schema support? That's certainly a thought, so long as we're ready for the onslaught of bogus bug reports... >I might be good to put it on a branch regardless. Did you mean "It" here, or were you volunteering? :-) >> - port/move the v1.util.regex package to util.regex >I don't know about this one. I would like to keep the code modular which means that we should try to keep the packages separate. Since the regular expression code is only needed for Schema validation, I think that it should be under the impl.schema package. Fair enough. >> - 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. > Validation is not inherently something needed in either of these two pieces, so it shouldn't be included. Validation is already contemplated in the pipeline and we've got to provide some standardized, general way for validators to find their food. > And I have serious reservations about trying to define grammar information for inclusion in XNI. The reason is that I don't think any single grammar model can adequately capture all sets of XML grammars. 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 agree with you that we can have very little detail here. >> - find a sensible home for v2.SAXParser, v2.SchemaParser, > v2.SchemaParserConfiguration >Well, if things are really going as well as you say, I think that we won't need this because we can put the Schema validator into the standard parser configuration used by both the DOM and SAX parsers. Wouldn't we rather have a StandardSchemaParserConfiguration extending StandardParserConfiguration or something like that? Just a thought. Cheers, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
