Why are declared interfaces important?
Declared interfaces, like clean air and clean underwear, are easy to take for granted until you don't have them. I used to do my OO programming in Smalltalk, which is a great language; but one deficiency I always felt (and this is heresy for a Smalltalker to say, but I'm saying it anyway) is the runtime binding--what I came to think of as extremely weak typing. Smalltalk variables had no declared type/class, so practically any code with correct syntax would compile. It wasn't until runtime, when a client invoked a message on an object, that the environment determined the variable's object's class and looked at the class to see if it implemented a method with that signature. So you didn't really know if your code worked until you ran it, and you got lots of runtime errors that finally uncovered your simple programming mistakes.
I always thought there had to be a better way, and I discovered one in Java: interfaces. An interface is a contract between an object and a client using the object. The object promises to implement methods with these signatures, and the client promises to only invoke messages with these signatures; the object's class can implement those methods any way it wants to, and the client can depend on the signatures not changing even if/when the implementation does. New classes that didn't exist when the client was written can nevertheless work properly for the existing client simply by implementing the agreed-upon interface. Different implementations (classes) are interchangeable not because they coincidentally happen to implement some common set of signatures, but because they declare that they implement the same interface. (This interface vs. implementation thing also makes the distinction between abstract and concrete classes much more meaningful.)
Data can also suffer from weak typing. For the generator and consumer of some data to exchange it successfully, they have to agree on the format. When they don't agree, either the consumer derails with parsing errors, or worse yet proceeds (seemingly successfully) with incorrect data. When data exchange problems are detected, the developers fall into a blame game: "Your generator code is producing incorrectly formatted data." "No, your parser code can't parse the correctly formatted data." Resolving this dispute can be difficult.
XML does for data what Java interfaces do for code: It strongly types the data by declaring its schema (much like the DDL for a relational database schema). XML data has to be well formed to be parsed. It can also be valid, meaning that it fits the agreed-upon data structure. That structure is declared in an XML schema which the XML data is validated against. So when the consumer of some XML data can't consume it successfully, the development teams have a much more objective and less political means to determine where the problem is: a validating parser. Either the XML data validates against the schema--in which case the consumer has a bug--or it doesn't--in which case the generator has a bug (or the data validates yet the consumer finds flaws in it, in which case the schema needs to be improved). The schema is definitive (at least to the limits of a schema's ability to capture a program's intent), and is declarative so that it can be used by a variety of parser implementations. I like this idea so much that I tend to believe that almost all XML data should be validated before or as part of being consumed, or better yet, before even being sent (no use taking up bandwidth transmitting invalid data). (For example, see Validating XML in WAS and The Message Validator Pattern.)
I see SOAP and WSDL as making Web services strongly typed. A SOAP message is an envelope whose payload is an XML document, and that document should have a schema it can be/is validated against. WSDL declares an interface the way a Java interface does, and (usually) declares the incoming parameters and outgoing return types as XML documents with schemas the messages can be/are validated against. This helps ensure that a consumer and provider implemented independently still work together. And when there's a problem, it helps narrow down where the problem is: either the consumer invoking the service isn't conforming to the WSDL properly, or the provider implementing the service isn't. That doesn't fix the problem, but it tells you who needs to fix it.
So declared interfaces are a good thing, both for code and data. Can we agree on that?