WhatfettleRPC/doc-literal divide


Great post from Tim commenting on Jon's post on Eric's TV appearance [--that's enough name dropping]. Whilst I agree it's possible to be rpc or document based regardless of whether your WSDL description is rpc, document or documentwrapped I think there is one profound difference between encoded and literal, and that's interoperability.

Encoding is all about mapping and binding data into programming models and databases. It supports graph structures, encourages Schema annotations in the message in the form of xsi:type as well as a bunch of data structures under the control of the Section 5 soapenc attributes, which is particularly useful when binding dynamic languages such as Perl and Python. Most of all, it constrains the vocabulary of Schema used by WSDL to describe those messages. All this makes databinder to databinder tools interoperate well but processing encoded messages a nightmare at the document level in XML, SAX, DOM, XPath and wot-not. It's impossible to transform XML into a SOAP encoded document generically - you need access to the per message description.

In a marvelous piece of aspiration and led by Tim's seminal MSDN article, the WS-I Basic Profile deprecated encoding, which was all well and good, but opened up code generators and soapbuilders to the full gamut of a W3C XML Schema description. Three years on, and Databinding tools used by so many to process Web services are still struggling to interoperate with literal documents, and Schema authors are clueless if their description is going to work with their customers' toolkits.

Shameless plug: Enter the W3C XML Schema Patterns for Databinding WG, chartered to deliver a pair of W3C Recommendations to specify how to describe messages in XML Schema and yet interoperate with Databinding tools. Ask serious questions of anyone who sells you a databinding tool and isn't planning to participate in this important new Working Group!

Technorati Tags: , , ,