xerces-j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [ANN] XInclude processor for xml-commons
Date Wed, 30 Apr 2003 15:04:24 GMT
on 4/29/03 6:41 PM Neil Graham wrote:

> 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?  :)

Can you tell us why SAX is not powerful enough for what you need?
Caution: I'm not sarcastic, just curious.

> 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?  :)  

It does. But Cocoon is *entirely* built around SAX. Moving to XNI is an
incredibly difficult task. Nobody will do that just for the sake of it.
And since Cocoon almost never validates and cocoon already has xinclude
transformers built around SAX. I really don't see a need for such a
massive transition.

of course, this might well be blindness from our side or simply
ignorance on the XNI paradigms.

> 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...

SAX is much more used than XNI and this will containue to be so for a
long while, independently of its technical merits. This is a fact we
simply cannot forget to take into consideration.

>>Dumb proposal: why not a XNI2SAX Filter that uses an XNI processor for
> 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?

Yes and it's obviuos that such a XNI2SAX filter existed because Xerces
has to emit SAX events.

Now, please, help us understand: what are the differences between XNI
and SAX and what would we gain basing the entire cocoon architecture
around XNI events instead of SAX events?

Also, would would be the cons?

TIA for this.


To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

View raw message