Neil Graham wrote, On 29/04/2003 16.23:
Hi Joerg,
IMO it's called for a more modular architecture: have a parser, an XInclude processor, a validator, an PSVI constructor,
Which is, of course, the whole point of XNI--not to mention that Xerces provides all these components--except for the XInclude processor. :)
so I'd think as a parser feature XInclude has to be happen before validation. If someone wants to validate before XInclude, he can add a separate XInclude processor at a later stage.
[...]Let's stick with SAX, we have a formal documentation about the API and how it's supposed to work.
In your original post, you'd mentioned that you'd implemented this as a "SAX filter"; did you mean that it's an XMLFilter implementation? If so, and you're using a standard XMLReader implementation of some sort, then how do you do XInclude processing before validation?
Ooooh, opening a can of worms ;-)
Yes having used XInclude I can solemly state that XInclude has to occur before validation. The question is: should a parser validate? ;-)
The fact is that Processors like Cocoon will always have other methods to use before a validation, so what we (Cocoon) need is instead a validating transformer, or something like that.
Not that I'm defining solutions, just that Xerces is monolithic seen from a SAX-adhering processor world.
...
Again, I'm not saying that Xerces is the only possible home for such a project--just want to make sure that what's done makes sense for as wide a user-base as possible.
I think that loads of project would use a standalone version of XInclude. Shall it be SAX? Shall it be XNI?
Dumb proposal: why not a XNI2SAX Filter that uses an XNI processor for SAX? I'm surely missing something here, what is it?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------