cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [cocoon3] Stax Pipelines
Date Wed, 03 Dec 2008 11:35:28 GMT
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 Wallez -

View raw message