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 - http://bluxte.net
