mark nottingham

XOP and MTOM

Saturday, 14 February 2004

Web Services

The XML Protocol Working Group (of which I’m a member) has released a first draft of XOP, XML-binary Optimised Packaging, and a revised draft of MTOM, the Message Transmission Optimisation Mechanism, that leverages XOP.

In a nutshell, XOP is an alternate serialisation of XML that just happens to look like a MIME multipart/related package, with an XML document as the root part. That root part is very similar to the XML serialisation of the document, except that base64-encoded data is replaced by a reference to one of the MIME parts, which isn’t base64 encoded.

This allows you to avoid the bulk and overhead in processing associated with encoding, the only way that you can fit binary data directly into an XML world.

XOP can be used for any XML-based format; MTOM is just a description of how XOP is layered into the SOAP HTTP transport.

Overall, I’m very happy with the way that XOP and MTOM have turned out; this particular area has been taking up a lot of my energy for more than a year now, and it’s good to see that the work we put into explaining the problem and making a first go at a solution paid off.

I do have some concerns remaining, however. One of them is the perceived complexity of XOP, because it describes itself using the XML Query Data Model. Although it points out that XQDM isn’t necessary for implementation, I think this fact will be overlooked by a lot of scared developers, who only see a lot of jargon and layers of abstraction covering up what is, in fact, a very simple spec.

Another issue is regarding the kinds of data that XOP can optimise; right now, it only allows base64, but I very much wonder if this will prove to be a limitation.

A final, more external concern is that people will lump XOP into the same bucket as pure-binary serialisations of XML, which is also being discussed at the W3C. I’m more and more circumspect about the viability of doing so; finding a solution that can meet a large portion of the varied requirements of the community seems exceedingly elusive. From first reactions, it doesn’t appear this is going to happen, luckily.

For me, this effort has also been instructive; we’ve been able to introduce a technology, get consensus on it and publish drafts in a very short amount of time, disproving the notion that the W3C is intrinsically slow and a producer of bloated specs.