On Mon, 2003-09-01 at 21:43, Andreas Hochsteger wrote: > Hi! > > I just found these links: > * http://jcp.org/aboutJava/communityprocess/first/jsr173/index.html > * http://otn.oracle.com/oramag/oracle/03-sep/o53devxml.html > > Is there anyone who can tell me, if Cocoon can benefit from this > alternative parsing model? > Would it be possible to integrate it somehow? > Are there some performance improvements to expect? >
Given that stax is a pull api, you can't really make a pipeline of stax-components like you do with sax. You would need to buffer the parsing events in between stax-stages and run the different stax-stages on different threads. This would be possible of course, you could even make such a transformer in Cocoon as it is today. In fact, Xalan in incremental mode works that way: buffer incoming events from the first part of the pipeline, and a second thread reads them to do the xslt on it and sends events to the rest of the pipeline. Nekopull also uses such type of trick, though it only uses one thread: each time the pull-client asks more events and the buffer is empty, nekopull asks xerces to parse some more and buffers the parse events it receives. The main benefit of stax is that pull-parsing api's are generally easier to interpret an xml structure, it's more similar to walking through a tree structure. (there's enough stuff to find on this on the web) -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
