XML first, focus on the contract

Yet another blogosphere permathread started by Tim and Clemens, with great input from Steve. Stefan chimes in responding to Dare's comments on the topic. I have to say I totally agree with Tim and Stefan, but I think Steve nails it:

... starting from the implementation language and generating your contracts from it is just plain wrong, wrong, wrong, at least for systems of any appreciable magnitude, reach, or longevity.

...

When you start with the code rather than the contract, you are almost certainly going to slip up and allow style or notions or idioms particular to that programming language into your service contract. You might not notice it, or you might notice it but not care. However, the guy on the other side trying to consume your service from a different implementation language for which your style or notions or idioms don't work so well will care.

Exactly right.

To Dare's point:

It is actually much easier to make an uninteroperable Web service if one starts with the service contract instead of with object oriented code. The reason for this is quite simple and one I've harped on several times in the past; the impedance mismatch between XSD and objects is quite significant. There are several constructs in W3C XML Schema which simply have no counterpart in traditional object oriented languages which cause current XML Web service toolkits to barf when consuming them.

Patient: "It hurts when I try to map XSD to domain objects".
Doctor: "Don't do that".

Interestingly, the sentiment expressed in Dare's post is roughly that which motivated WS-I to charter the XML Schema Planning WG. Some wanted WS-I to profile (subset) XSD to the set of constructs that can be readily, and interoperably consumed by available tooling (what I would term the LCD approach). Others (like me) wanted to preserve the sentiment behind R2800 in Basic Profile 1.x.

There are a number of issues at play to be sure, as I have written about previously. Available tooling, in many cases, does an inadequate job of databinding for some schema constructs. JAX-RPC1.1, for instance, permits optional support for certain schema constructs; thus what might work in one vendor's offering might not do so portably in another's.

There are also issues with regards to consistency between various schema development tooling as to what is, and what is not, valid schema and as to what instances are, or are not, valid with regards to a given schema definition.

While WS-I has not yet formally decided upon a specific course of action, there will certainly be a decision made in the very near future.

Ultimately, I think the tension is between those who think of XML and Web services in terms of domain objects in their favorite programming language (XML? What XML?), and those who embrace the XML (Objects? What objects? This is a document). I suspect the truth lies somewhere between these two extremes.