Neil Graham wrote, On 30/04/2003 1.41:
Hi Nicola Ken,
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 ;-)Both commons-dev and xerces-j-dev have been really quiet lately; about time
for some activity! :)
:-D
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.
I see what you're saying, I think: you like the idea of a componentized parser that operates in a pipeline, but you wish that SAX had been used as the glue for such a beast, rather than its own API. Right?
And if SAX had seemed rich and complete enough, and had it supported the kind of configuration-management facilities that are needed for such an arrangement, I imagine that's the road we would have gone down. But it isn't/doesn't, so what was there to do? :)
Yeah, I know... I read about XNI, so I'm aware of the reasons it was created...
So I guess I'd turn the question around: If using SAX means you're stuck with monolithic-looking parsers, but XNI would give you a parser with all kinds of flexibility, maybe using XNI might merit consideration? :) Sure it would bind you to a specific parser (until other parsers begin to use XNI :)) ), but if you write your own SAX-glued parser then you're stuck to that anyway...
...which brings us to the real catch22 problem, as Xerces needs XNI but all systems out use SAX. Why not only extend SAX? (ignorant mode)
Dumb proposal: why not a XNI2SAX Filter that uses an XNI processor for SAX?
We already have one: org.apache.xerces.parsers.SAXParser; heck, it even understands both SAX1 and SAX2! :) The trouble is that, once you're emitting SAX, you're not in the Xerces pipeline world anymore; so this guy is only useful at the end of such a pipeline (whatever XNI components that pipeline has in it). So there's no way of putting a Xerces validator after that component, for instance (to do so would kind of defeat the point of XNI). Does that explain anything?
Is it impossible to do validation of a document from a SAX stream? Or is XNI compulsory?
Is it possible to do XInclude from a SAX stream? Or is XNI compulsory?
Is there a real possibility of hacking the SAX pipelines to make this happen for *some* components like validation or XInclude?
Here's hoping I haven't let too many more worms out of that can...
No, you have been very on-the-spot :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------