Introducing stax-ex project
We've been using StAX API more and more lately. Its support is added in JAXB a while ago, JAX-WS RI has started using it internally, and now with the rearchitecture, the JAX-WS RI is using StAX API more extensively internally.
As a part of the rearchitecture, Paul Sandoz and I were talking about the need of a few small extensions to the StAX API.
For example, we'd like to handle MTOM below the StAX API, since it's a kind of XML encoding. But when we do that, we'd like to acecss the binary data more efficiently than turning it into base64-encoded text. This also allows FastInfoset to pass through its binary data to client applications, like JAXB.
Another area that needs a fix is the poorly designed NamespaceContext. What we needed in the Java platform was a very simple NamespaceResolver (that just resolves prefixes to URLs and useful for XPath parsing and etc), and then more comprehensive NamespaceContext that exposes complete hierarchy of in-scope namepsace bindings for parsers. But today's NamespaceContext tried to be both at the same time, and it ended up neither. The consequence of this for StAX is that there's currently no way to enumerate the complete in-scope namespace bindings, and this hurts.
This discussion initially started in the firstname.lastname@example.org list, but we eventually realized that it needs to get its own home, so that components like SJSXP, JAXB, FI can all refer to it and make use of it.
So today we created the stax-ex project for this purpose. The project hosts a few interfaces that inherit the interfaces defined in JSR-173. So in some sense it works like optional add-on to the JSR-173 interface.