On Tuesday, 04/09/2002 at 07:44 AST, [EMAIL PROTECTED] wrote: >I thought our implementation was merely the > *reference* implementation of XNI
For what it's worth, that's the impression this user got too... XNI's goal, as I understood it, we specifically to componentize the parser so those components -- and others -- could be assembled in whatever combination or order suited the application's processing model, thus both allowing the concept of "XML Processor" to be extended as new specs are introduced (as working drafts and/or recommendations) and permitting folks to leave out stages which don't affect their application. XNI should probalby still be considered experimental and subject to change. And there are probably some calls which are currently lumped under the XNI banner which _should_ be considered parser internals. But there needs to be some reasonable application-level control over XNI parser configurations, and that part of XNI is definitely _not_ internals... or, if it is, we need an equivalent application-level API. Take your pick. (Personal pet peeve, which I've cited before: Incremental parsing. That's definitely an application-level issue, and the only way to access it right now is through XNI.) So: Experimental, yes. Partly internal, probably. Entirely internals? I don't think so. > I suggest we design API's that meet the real need that caused us to go down > this path, and then implement them. Makes sense to me. Re grammar caching: Y'know, I'm _NOT_ convinced that there should be a single Grammar Cache for all grammars. This sounds like the sort of thing that ought to be a feature of the grammar engine rather than of Xerces as a whole. Providing a reference implementation of a document (entity?) cache would be a good thing, and might also be of interest for folks who want to cache instance documents. Having an API which allows easily plugging that into grammar engines, entity resolvers, etc. would probalby be a good thing. But I think we need to allow for the fact that some users may want to cache only DTDs and not schemas, or vice versa, or may want to be more selective about which ones they do and don't cache. To make the best caching decisions, I think we need to know not only the public/system ID but what purpose the entity is being requested for... and I'm not convinced that putting all the logic to tease that information apart into a single central cache is better than having individual caches plugged in at specific points (which may then delegate to a central cache IF that's what makes sense for this application). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
