cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neil Graham" <ne...@ca.ibm.com>
Subject Re: [ANN] XInclude processor for xml-commons
Date Mon, 05 May 2003 22:38:47 GMT
Hi Stefano,

Sorry about the delay; I was really hoping that Andy Clark (the "Father of
XNI") would pick up this thread.  He'd do a much better job of contrasting
XNI with SAX, and especially giving you the historical angle (I came on the
scene a bit after XNI had gotten out of the crib, so by then the decision
to break from SAX was already made).

> Can you tell us why SAX is not powerful enough for what you need?

Well it's turned out to be pretty handy to be able to pass "augmentations"
along with the events representing the infoset.  SAX doesn't have any kind
of configuration-management infrastructure:  If you want to set up a
pipeline of XMLFilters then you have to manage propagation of features and
properties to the components that comprise the pipeline on your own; XNI
sorts this out.  SAX is also somewhat impoverished for people who care a
great deal about the lexical layout of DTD's; there isn't much you can't
get in this respect from XNI.  Although SAX 1.1 extentions (still in
alpha!) could rectify this, as it stands it's not possible to determine the
version or encoding of a document with "stable" SAX interfaces.

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

I can understand that.

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

I think my question revolved around Joerg's assertion that the spec thinks
of XInclude processing being done before validation.  If you don't do
validation of any kind anyway, then clearly this won't disturb you; but if
you did--or wanted to follow as closely to the spec as possible--then you'd
be confronted by the fact that most SAX parsers have validation built in,
not built as a separate module that you can drop an XInclude processor in
front of.

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

At this stage, I'm afraid the biggest pro might be that SAX just doesn't
seem to be all that healthy these days; I don't know if you lurk on its
development lists, but they've been pretty much dead for quite some time...

But I'll leave the hard job of selling XNI to Andy; it works well for us,
but perhaps SAX is good enough for what you need it to do.  Cocoon being
the huge project it is, I certainly wouldn't blame you for needing some
very solid reasons to migrate to a different pipeline framework!

Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone:  905-413-3519, T/L 969-3519
E-mail:  neilg@ca.ibm.com




|---------+---------------------------->
|         |           Stefano Mazzocchi|
|         |           <stefano@apache.o|
|         |           rg>              |
|         |                            |
|         |           04/30/2003 11:04 |
|         |           AM               |
|         |                            |
|---------+---------------------------->
  >---------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                      
                                                      |
  |       To:       cocoon-dev@xml.apache.org                                            
                                                      |
  |       cc:       commons-dev@xml.apache.org, xerces-j-dev@xml.apache.org              
                                                      |
  |       Subject:  Re: [ANN] XInclude processor for xml-commons                         
                                                      |
  |                                                                                      
                                                      |
  |                                                                                      
                                                      |
  >---------------------------------------------------------------------------------------------------------------------------------------------|



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

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.

--
Stefano.






Mime
View raw message