cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simone Tripodi" <>
Subject Re: [cocoon3] Stax Pipelines
Date Thu, 04 Dec 2008 15:05:21 GMT
Hi All,
very nice and interesting thread, congratulations!!! I've exactly your
same feelings, I can't wait to see the first components, but my
curiosity is focused more on seeing how the Stax and Sax components
will be integrated :)
I'm not able to give my contribution in this area, since I'm not
expert on Stax, so I can just support you!
Best regards!!!

2008/12/3 Sylvain Wallez <>:
> Steven Dolg wrote:
>> Thorsten Scherler schrieb:
>>> El mié, 03-12-2008 a las 08:56 +0100, Sylvain Wallez escribió:
>>>> Andreas Pieber wrote:
>>> ...
>>>>> One big "problem" in this approach is that the "flow direction of
>>>>> events" is completely inverted. This means that StAX and SAX components
>>>>> would not be able to work "directly" together. But also in a push-pull
>>>>> approach a conversion between StAX and SAX events have to be done and
>>>>> further more this problem could be tackled by writing a wrapper or adapters
>>>>> around the SAX components and add them to an StAX pipe.
>>>> Absolutely. Converting Stax to SAX is fairly trivial, but the other way
>>>> around requires buffering or multithreading. Have you looked at Stax-Utils
>>>> [1]? It contains many classes to ease the SAX <-> Stax translation.
>>> I lately played around (and still do) with such approach in the forrest
>>> dispatcher rewrite [3]. I am using Axiom which is a quite interesting
>>> approach and maybe worth looking into [4]. However I did some profiling
>>> and for the dispatcher the old SAX approach had been ways faster.
>> We started with an evaluation of some StAX implementations including
>> Axiom, WoodStox and the reference implementation.
>> However quite early we felt that the DOM-like approach of Axiom is not
>> ideally suited for our current phase.
>> I'm quite sure that there are occasions where Axiom can be really
>> charming, but I believe there are too many premises required to efficiently
>> use it (e.g. you will want to be sure that the XML data is not too large).
>> But if you have some complex transformation that appear to difficult to be
>> implemented in a one-pass approach Axiom could probably do the trick.
>> I'm sure we will explore this idea at a later time, though...
> Axiom is very interesting as the DOM-like structure it provides is the
> easiest way to traverse a document while avoiding full parsing of the
> document. But this comes with a price, since any traversal on a list of
> elements requires to parse all of these elements. So without very careful
> use, it can quickly degenerate into a classical DOM with the assiociated
> problems, or even worse because of the additional complexity required by
> deferred parsing.
> Not to say that Axiom is bad, rather the contrary: it's a powerful weapon
> which you can easily shoot yourself in the foot with :-)
>>> However this is due to the buffering issue pointed out by Sylvain which
>>> [5] is not solving at all. Brings me back to do a sax (+stax) approach
>>> again (the other class in the package).
>>> I am really exited about this thread. :)
>> I must admit that it got me all excited by now, too.
> Should I say me too? ;-)
>> Yesterday, I did a very minimalistic POC, just to make sure our current
>> approach is not missing any major point.
>> I have to say I was simply amazed how easy state handling can be when
>> using StAX compared to SAX and I'm very confident that we came up with a
>> pretty thorough concept.
> I'm eager to see what it looks like!
>> After all, we tortured our poor students more than a month with evaluating
>> implemenations, writing uses cases - outside Cocoon! - using both SAX and
>> StAX, before even "allowing" them to think about how to integrate this into
>> Cocoon.
>> I believe this was necessary to fully understand the differences between
>> StAX and SAX and - even more important - the different usage patterns
>> associated with them.
>> And I'm sure this allows us now to fully reap the benefits of this API.
>> Well, I can't wait to see the first components ...
> Same here! But don't forget in the torture program the important XSLT
> transformer, since I don't know of any implementation that would support
> pull callbacks and thus avoid buffering the ouput in a Stax pipeline.
> Sylvain
> --
> Sylvain Wallez -

My LinkedIn profile:
My GoogleCode profile:
My Picasa:
My Tube:
View raw message