WSDL and XSD and Policy are interoperable metadata exchange formats. That’s just about it. The metadata that’s contained in artifacts compliant with these standards can be expressed in a multitude of different ways. 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.
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. If you use Indigo, you can do the same and, in fact, for generating any XML-based metadata from within an Indigo service, it’s even required to explicitly add the respective service behavior at present. The required metadata to make services work comes in many shapes or forms and is, for a given tool, typically richer than what you will find in the related WSDL/XSD/Policy, because not all that metadata is related to the wire format itself.
If I need to tell someone who is not using my tool of choice how to talk to my service, I have my tool generate the respective metadata exchange documents and I want to be able to trust my tool that they’re “right”.
What I am stating here is simply my demand and expectation for the degree of “automatic interoperability” that I expect from the tools. I can read WSDL/XSD/Policy; out there, most people absolutely don’t seem to care about these details and I tend to agree with them that making this stuff work is someone else’s problem.
I don’t need to be able to read and write PDF to use PDF. I use PDF if I know that someone will open my document who is not using Microsoft Word. Still, that PDF doc isn’t the document. My Word source document is the document I edit and revise. The PDF is just one of several possible representations of its contents.