Clemens responds, and I think maybe we actually agree

Clemens posted a response to my original post about his position on Indigo contracts. In it, he says:

WSDL and XSD and Policy are interoperable metadata exchange formats. That’s just about it.

I agree. It's the information you exchange in these files and in documentation that forms the contract. He also says:

But WSDL/XSD/Policy isn’t the contract. If you do ASMX, you can create server and client without you or any of the tools ever looking at or generating WSDL. And it works.

The fact that it just works doesn't mean that WSDL/XSD/Policy is not the contract. It means that you don't care to see the contract and deal with it directly.

The part that Clemens and I agree on is this:

I do care about “my tool” (whatever that is) to do the right thing mapping from and to these metadata standards whenever required and I do care about “my tool” guiding me to stay within the limits of what these metadata formats can express.

The problem today, as I see it, is that tools aren't actually very good at that, as evidenced by the problems people have getting their tools to emit contracts that actually express their desires and that their clients can consume. The reality today is that if you care about your client being able to EASILY consume your service, independent of toolkit or platform, you have to care about your contact. If you author it indirectly using source code, you need to not only know how XSD and WSDL work, but how your tool maps to them as well.

There is another orthogonal aspect to this as well. Real loose-coupling between services will come when people actually leverage the composibility and open content model aspects of XML. If you start from OO code to generate your contract, you are unlikely to do that. How many loosely-coupled OO models have you seen? Translating them to XSD won't give you loose-coupling, it will give you tight-coupling in another language.