Hi Andy, >>But it seems to me that grammar preparsing is analogous in many ways to > pull parsing. >>Our pull parsing functionality is part of XNI--through the
>In what ways? ;) Well they're both useful absolutely as well as in conjunction with standard API generators. >Let's be sure about what it is that we want to add to the (still experimental) xni.grammars >package. The configuration interfaces available in xni.parser are there so that you can >drive various API generators (e.g. DOM, SAX, etc) from different parsing pipelines. And with different properties. Components aren't quite the only concept in XNI, aven if properties aren't nearly as well-defeind. Here's what I see people wanting to do: - create new configuration with properties/pipeline config they want; - set features on it etc. - in this case, use it to load up the store of grammars to be used with the standard parser; - Create the parser with this configuration and pass it off to the application logic which actually interacts with parsers (and might be able to be written very much more generically than the code which detects and exploits Xerces) That's also why I wouldn't mind seeing methods like lockGrammarPool and co. on the configuration. People (Joe Kesselman for instance) have complained that even requiring users to know about configurations is bad; if we can localize the learning code to one interface as much as possible, I think that's a good thing. But if you're really opposed I can settle with a set of parseGrammar methods on this putative configuration. > However... Currently, in the xni.parser package we have interfaces to define a grammar, a > grammar description, and a grammar pool. In the xni.grammars package you mean. > register an error handler and entity resolver. Right; we could force people to build their grammar pools with one interface then set them on the configuration of their choice which actually drives the document parsing. I just think this is too complicated for the general case--look at all the folks who use our ASBuilder sample, despite the idiosyncracies of the interface it's based on! (Nothing wrong with being idiosyncratic of course; this conception of grammar preparsing/caching is just very different from what we've built in XNI, and our implementation of it probably needs to change one day...) > We don't need a separate method for loading by URI if we have a method that takes an >XMLInputSource. I deliberately kept the parsing on the XMLParserConfiguration interface to >a single method to avoid the JAXP problem with an explosive amount of parse(...) methods. >So I'd like to see any new interfaces follow suit. All right. Just trying to mirror what we do today in XMLGrammarCachingConfiguration (which I thought must have received consensus while I was away somewhere...) Hope to hear from you further Andy; seems like only you and I are following these threads these days... Cheers, Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
