The St AX project was spearheaded by BEA with support from Sun Microsystems, and the JSR 173 specification passed the Java Community Process final approval ballot in March, 2004 ( The primary goal of the St AX API is to give “parsing control to the programmer by exposing a simple iterator based API.
While providing a smaller memory footprint, reduced processor requirements, and higher performance in certain situations, the primary trade-off with stream processing is that you can only see the infoset state at one location at a time in the document.
Moreover, unlike SAX, the St AX API is bidirectional, enabling both reading and writing of XML documents.
The St AX API is really two distinct API sets: a cursor API and an iterator API.
Of the latter two, St AX is not as powerful or flexible as Tr AX or JDOM, but neither does it require as much memory or processor load to be useful, and St AX can, in many cases, outperform the DOM-based APIs.
The same arguments outlined above, weighing the cost/benefits of the DOM model versus the streaming model, apply here.
Please refer to the St AX specification for further information.