[via Boing Boing] I still don't have an opinion about Howard Dean as a presidential candidate, but I like the way that his campaign is reaching down to the grassroots. I also like the idea of the DeanSpace project. I don't know if the software is any good or not. In way, that's not the point. The politcal process seems very wasteful, in the following sense: During the buildup to the presidential election, there's a lot of effort that goes in, but at the end there's a single winner. That's all that's left of all of the massive efforts. What I like about DeanSpace is that something will be left behind. If DeanSpace, the software, works, some other candidate might be able to pick it up and use it. I like the fact that they open sourced this -- this is definitely the kind of software that should be free. But it's more than just the software, because DeanSpace is "social software", so there's a chance that the social network formed by DeanSpace might persist after the election in a way that hasn't previously happened. It seems to me like there'd be something left that could be built upon. It's going to be interesting to watch what happens with this.

Eliotte Rusty Harold has an XML.com article on StAX. It's a good introduction to this style of API.

He didn't like the use of integer type codes, preferring to have objects. I view StAX as a replacement for SAX, which is basically the bottom of the stack for XML processing API's. You can use SAX or StAX to build trees or beans or whatever you like. So any performance penalty that you impose on StAX is something you've imposed on everybody above you in the food chain, and there's no way to get that performance back if you need it. I think that they did the right thing here. The performance of reflection is never going to match integer comparison. Also, Andy Clark, the author of NekoPull is a member of the expert group as well.

As noted, the state management is much easier than SAX -- it allows you to write a more recursive-descent style of object construction. One of the problems with SAX is that it's very hard to use it to create objects in a way that allows you to reuse the objects and the SAX handler for building those objects. StAX makes that go away.

In many cases what you want is an easy to manipulate representation of the XML data. This is very frequently a Java Bean. So what you really want is an API that takes an XML stream, and gives me back the right Java Bean. And that's what XMLBeans is all about.

So in my view of the Java XML API world, there's StAX at the bottom, and on top of that you have XMLBeans. If you need to do weird document editing tree stuff, then there's StAX at the bottom, and on top of that there's the DOM or XOM or JDOM or whatever. But for most applications that I've worked on, the combination of StAX and XMLBeans would cover it. If you look at the XMLBeans Roadmap, you'll see that one of the goals is to support StAX (JSR 173), which would mean one stop shopping, er, downloading. My hope is that as XMLBeans evolves we'll be able to have a simple to use library.