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!!! Simone
2008/12/3 Sylvain Wallez <[EMAIL PROTECTED]>: > 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 > > -- My LinkedIn profile: http://www.linkedin.com/in/simonetripodi My GoogleCode profile: http://code.google.com/u/simone.tripodi/ My Picasa: http://picasaweb.google.com/simone.tripodi/ My Tube: http://www.youtube.com/user/stripodi My Del.icio.us: http://del.icio.us/simone.tripodi
