Tuesday, June 05, 2007

WADL: its really about the XML APIs

There has been a bit of hubbub about WADL recently. Much of the conversation is about the need to describe the message using XSD and the benefits of WADL/WSDL for tooling. (I'd provide a Technorati search link, but Technorati appears down at the moment.) I think the real problem is that most XML APIs are so horrid to use. People want RPC (at least until they get burned enough to know better), and even when they know better they was the initial simplicity of RPC. One of the big problems with XML is that it is a horrid match with modern data structures.

You see, it is not that it isn't trivial to figure a way to serialize your data to XML; it is just that left to their own devices, everyone would end up doing it slightly differently. There is no one-true-serialization. So, eventually, you end up having to write code to build your data structures from the XML directly. The problem there is that virtually all XML APIs are horrible for this kind of code. They are all designed from the perspective of the XML perspective, not from the data serialization perspective.

It gets worse. XML is one of those things that looks really easy, but is actually full of nasty surprises that don't show up until either the week before you ship (or worse.., a few weeks after). Things like character encoding issues, XML Namespaces, XSD Wildcards. It is really hard for your average developer (who makes no pretenses at XML guru-hood) to write good XML serialization/hydration code. Everything is stacked against him: XML APIs, XML -Lang itself, XSD.

That is why so many developers (especially in the Java world) just use XML Binding layers.

Solution? Give them a good XML API. Not one designed for XML Gurus, who understand every nuance of the spec. Give them an API that makes using XML easy, and relatively efficient. This ain't easy, or it would already be there. XLinq is C#'s answer to exactly this issue. Java needs something similar. An XML API that isn't designed primarily for XML as text markup, but an XML API that is designed for data serialization.


Blogger elarson said...

The other option is to not use XML for serialization. This may not seem like a good idea but when you stop considering XML as data and only use it as a document, then it becomes much easier to work with (IMHO).

I realize many folks may disagree with that one, but recently I have quite trying to make objects and simply started working with XML and the results have been very concise and well organized. My tools of choice have been Python and XSLT, which may have something to do with it.

With that said, I do agree that many XML APIs are really poor and have gotchas around many corners. I suppose my only point is that there are fewer gotchas when you cease to make an effort de/serialize XML to/from objects :)

9:52 AM  
Blogger Len Bullard said...

Agree with Eric. It was said a lonnnggg time ago in a place not far away: XML is a lousy object structure. We know how to force fit it but why is a different rant.

For all the reasons we know about.

I sit here staring into XML on-the-wire specs that are in themselves brilliantly done, but despair that the people who wrote them tried to design objects-in-XML with the usual layers of abstractions, then the customer specs a relational database and we will eventually have to write our own 'intercessor' schema or DTD to get around the indirections.

That said, I'm waiting for Linq. I may need it sooner than I thought. The idea of WADL reinforces that REST is still not enough. We want it to be, then we see the costs.

1:16 PM  
Blogger Andrew Welch said...

The javax.xml.stream package in Java 1.6 (was JSR 173) makes things a lot easier, although I'm guessing still not quite what you're after.

2:19 AM  

Post a Comment

<< Home