Comments on: The complexity of XML parsing APIs http://quoderat.megginson.com/2005/02/08/the-complexity-of-xml-parsing-apis/ Open information and technology. Wed, 01 Sep 2010 22:51:00 +0000 hourly 1 http://wordpress.com/ By: Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems http://quoderat.megginson.com/2005/02/08/the-complexity-of-xml-parsing-apis/#comment-42 Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems Sat, 12 Mar 2005 20:46:51 +0000 /?p=12#comment-42 <strong>POX: The plague in your enterprise architecture</strong> POX: The plague in your enterprise architecture

]]> By: Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems http://quoderat.megginson.com/2005/02/08/the-complexity-of-xml-parsing-apis/#comment-41 Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems Sat, 12 Mar 2005 20:42:27 +0000 /?p=12#comment-41 <strong>POX: The plague in your enterprise architecture</strong> POX: The plague in your enterprise architecture

]]> By: Dan Diephouse http://quoderat.megginson.com/2005/02/08/the-complexity-of-xml-parsing-apis/#comment-40 Dan Diephouse Mon, 21 Feb 2005 00:05:41 +0000 /?p=12#comment-40 Are you refering just to W3C DOM in Java (which definitely sucks) or to all DOM toolkits? Have you looked at <a href="http://www.xom.nu" rel="nofollow">XOM</a>? Are you refering just to W3C DOM in Java (which definitely sucks) or to all DOM toolkits? Have you looked at XOM?

]]> By: Software Documentation Weblog http://quoderat.megginson.com/2005/02/08/the-complexity-of-xml-parsing-apis/#comment-39 Software Documentation Weblog Fri, 11 Feb 2005 22:19:35 +0000 /?p=12#comment-39 <strong>XPath is a nice DOM wrapper, but what to do about SAX?</strong> 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 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 http://quoderat.megginson.com/2005/02/08/the-complexity-of-xml-parsing-apis/#comment-38 David Megginson Fri, 11 Feb 2005 19:07:58 +0000 /?p=12#comment-38 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. 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 http://quoderat.megginson.com/2005/02/08/the-complexity-of-xml-parsing-apis/#comment-37 Anthony B. Coates Fri, 11 Feb 2005 19:00:30 +0000 /?p=12#comment-37 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. 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 http://quoderat.megginson.com/2005/02/08/the-complexity-of-xml-parsing-apis/#comment-36 Dare Obasanjo's WebLog Wed, 09 Feb 2005 15:04:19 +0000 /?p=12#comment-36 <strong>On the Complexity of XML APIs</strong> On the Complexity of XML APIs

]]> By: David Megginson http://quoderat.megginson.com/2005/02/08/the-complexity-of-xml-parsing-apis/#comment-34 David Megginson Wed, 09 Feb 2005 12:18:44 +0000 /?p=12#comment-34 Thanks, Mike -- that sounds like a great idea for a future posting. Thanks, Mike — that sounds like a great idea for a future posting.

]]> By: Mike Champion http://quoderat.megginson.com/2005/02/08/the-complexity-of-xml-parsing-apis/#comment-33 Mike Champion Wed, 09 Feb 2005 02:33:05 +0000 /?p=12#comment-33 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. 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 http://quoderat.megginson.com/2005/02/08/the-complexity-of-xml-parsing-apis/#comment-32 Martins Notepad Wed, 09 Feb 2005 00:36:20 +0000 /?p=12#comment-32 <strong>Why do XML APIs suck?</strong> 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... 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 http://quoderat.megginson.com/2005/02/08/the-complexity-of-xml-parsing-apis/#comment-35 Danny Ayers, Raw Blog Wed, 30 Nov -0001 00:00:00 +0000 /?p=12#comment-35 [...] 212; Danny @ 14:26 David Megginson, developer of SAX has an interesting post on <a href="http://www.megginson.com/blogs/quoderat/archives/2005/02/08/the-complexity-of-xml-parsing-apis/" rel="nofollow">The complexity of XML parsing APIs</a>, partly in res [...] [...] 212; Danny @ 14:26

David Megginson, developer of SAX has an interesting post on The complexity of XML parsing APIs, partly in res [...]

]]>