Summary
In a recent IBM developerWorks article, Brett McLaughlin notes that the way most developers use XML has changed significantly over the years, possibly losing some flexibility afforded by the early XML APIs. What's your preferred way of interacting with XML data?
Advertisement
Earlier this year, Brett McLaughlin, an O'Reilly editor, and author of that publisher's Java and XML book, asked what tasks XML was really good for. In a new IBM developerWorks article, Low-level or high-level XML APIs?, McLaughlin asks a slightly different question: Once you decided—or are forced—to use XML, how do you prefer to interact with XML data? What APIs do you prefer to use?
I wonder who really does use working XML code these days, and what API (or APIs) they use. Is it true that hundreds, thousands, tens of thousands of you out there still plug away with SAX and DOM, comfortable writing your startProcessingInstruction() method, or have data binding and helper APIs completely taken over? (...)
And arguably more importantly, do you believe you still have the control and power over your XML? I pose this question particularly to programmers who have worked with XML since the early days when SAX was your only option for speedy XML reading, and DOM was the only choice if you wanted to deal with an XML document in object form. Do you find yourself working at a higher level, and are you OK with that? Or have we all become Turbo Pascal programmers while only a select few guys are popping the stack over on their ASM terminals?
In cases where I'm dealing with large XML documents (100s of thousands of elements) I usually go with a Stax parser to process it in a stream-based fashion.
Where the datasets are small, and I have control over both ends, I mostly use something like XStream or JAXB.
I have a variety of home grown solutions... they fall into two major categories
1. "SAXOM" - run across a path, and subparse the fragments into mini doms. 2. XpathResultSet - Imagine being able to get a resultset based on an Xpath expression and then just next() your way through each row to get whatever sub-xpath expression you want. I love this one actually, I'm working to try to open source my implementation.
Then I'll do stax once in a while...
I like programmatic apis. The "generate code and just use it" approach doesn't do it for me.
SAX. But that was 2 years ago. I haven’t done much Java+XML lately. Currently working at a VB.Net project where interaction with XML is limited to the System.Configuration.ConfigurationManager library. In Python I use ElementTree since it is included in the standard distribution.
But lately I have been working with RESTful web services and I have found it very useful to un/marshal the XML bodies of POSTs and PUTs using JAXB. What I really like about JAXB is that I no long need to write XSDs. I can build my model with annotated POJOs and if I need an XSD artifact, I can generate it.
> As little as possible. > > But lately I have been working with RESTful web services > and I have found it very useful to un/marshal the XML > bodies of POSTs and PUTs using JAXB. What I really like > about JAXB is that I no long need to write XSDs. I can > build my model with annotated POJOs and if I need an XSD > artifact, I can generate it.
So you've had goo success with generating XSD with JAXB? I've had really bad experiences with the code generated from a schema and the other direction looks a lot more promising.
> So you've had goo success with generating XSD with JAXB? > I've had really bad experiences with the code generated > d from a schema and the other direction looks a lot more > promising.
If it has been a while since you used JAXB, you might want to try it again. It's version 2.1.3 now. XSD to Java seems to work pretty well now too.
> > So you've had goo success with generating XSD with > JAXB? > > I've had really bad experiences with the code generated > > d from a schema and the other direction looks a lot > more > > promising. > > If it has been a while since you used JAXB, you might want > to try it again. It's version 2.1.3 now. XSD to Java seems > to work pretty well now too.
It wasn't that it didn't work properly, it's that I think that whole approach is misguided.
Apache XML beans for processing and generating documents. I always create an XML Schema. SAX for processing extremely large documents that will not fit in memory. Xalan for XSLT processing.
Previous Topic
