Comments on: The complexity of XML parsing APIs

By: Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems

Sat, 12 Mar 2005 20:46:51 +0000

POX: The plague in your enterprise architecture

]]>

By: Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems

Sat, 12 Mar 2005 20:42:27 +0000

POX: The plague in your enterprise architecture

]]>

By: Dan Diephouse

Mon, 21 Feb 2005 00:05:41 +0000

By: Software Documentation Weblog

Fri, 11 Feb 2005 22:19:35 +0000

XPath is a nice DOM wrapper, but what to do about SAX?
Martin Probst complaints about overly complex XML-APIs and recommends the use of XQuery as a language that can be used to work with XML data programatically, that does not suck.

In most cases XQuery is more than people need in their applications. I

]]>

By: David Megginson

Fri, 11 Feb 2005 19:07:58 +0000

Thanks for the comment, Tony. The template approach is a pleasant way to generate XML, whether through XSLT transformations (when used in a templatey way) or JSP — you have everything in front of you at once, just like in a fullscreen text editor (vs. the old line-oriented editors, which have a lot in common with programming code to manipulate XML).

The trouble is that the templates don’t really work for reading XML into objects or data structures, or for taking complex programming actions based on the XML. Also, XSLT (or DOM) can bring a busy web server to its knees because of the processor and memory requirements, though for some applications smart caching can help a lot.

By the time people get to the point of using a streaming API like SAX or StAX, they often have a serious problem like a sluggish application server and are willing to accept a lot of pain for the sake of curing it. It would be nice if we could figure out some middle ground, something that wasn’t as hard to use as a streaming API but not as maddeningly inefficient as DOM or XSLT.

]]>

By: Anthony B. Coates

Fri, 11 Feb 2005 19:00:30 +0000

Here’s the thing. I’ve been doing Java for rather longer than I’ve been doing XML, and yet, whenever I have to convert one kind of XML into another, I go straight for XSLT. Why? Well, I guess there are two things:
(i) XML is a genuine part of the data model in XSLT. So you don’t get stupid complications that arise from forcing the square peg XML data model through some round hole language data model. JavaBeans and C/C++/C# classes just don’t map neatly onto the XML infoset.
(ii) When you write XSLT, you can write fragments of XML directly, and embed bits of code within the XML fragments for the dynamic parts of the code. That often makes it vastly easier to see what the result will be like, and that just speeds up the whole development process.
What it all comes down to is that any XML API will suck where XML isn’t a first class data type, and where it isn’t integrated into the language syntax. Languages that allow XML (or even tree-structured data) are just easier to write and maintain (XSLT, E4X, Comega, Groovy), and some if not all can be compiled so that you don’t lose much in performance, but gain lots in development time.
That’s how I see it anyway. Cheers, Tony.
PS With JDK 5.0, it would be an afternoon task to write a compiler front-end that compiles both Java and XSLT 1.0 sources into Java bytecodes. Horses for courses? Could be.

]]>

By: Dare Obasanjo's WebLog

Wed, 09 Feb 2005 15:04:19 +0000

On the Complexity of XML APIs

]]>

By: David Megginson

Wed, 09 Feb 2005 12:18:44 +0000

Thanks, Mike — that sounds like a great idea for a future posting.

]]>

By: Mike Champion

Wed, 09 Feb 2005 02:33:05 +0000

Well since you admit that SAX sucks, I can agree that DOM sucks too 🙂 It’s very interesting and somewhat disheartening that you found the next generation of APIs better for simple things but no better for realistically hard problems. Obviously we have to do better, and its probably a good thing that nobody is trying to standardize XML APIs anymore so that innovation and competition can drive progress.

I wonder if you could suggest at least the outlines of a realistic application scenario that is complex enough to exhibit the problems you noted but simple enough to become sortof a common example that can be used as a reference point. Something more complex than Hello, World or the XQuery book database of course … maybe at the level of the Employee-Department-Manager-etc. Personnel database that one tends to see in every RDBMS book and tutorial.

We know how to make trivial XML programs trivial to write (in the next-generation-after-SAX/DOM APIs, anyway). It would be nice to make an interesting class of less trivial XML applications at least easy, and having a common reference example might help us all evolve in that direction.

]]>

By: Martins Notepad

Wed, 09 Feb 2005 00:36:20 +0000

Why do XML APIs suck?
The complexity of XML parsing APIs seems to be a general complaint about XML parsing APIs. So why do these APIs suck?

I’ve worked with the three major API styles myself (DOM, SAX, XML Push thingies) and yes, they do suck. But if you come to think a…

]]>

By: Danny Ayers, Raw Blog

Tue, 30 Nov -0001 00:00:00 +0000