In a recent post entitled Replacing WSDL, Twice  Tim Bray writes

Lets make three assumptions: First, that Web Services are important. Second, that to make Web Services useful, you need some sort of declaration mechanism. Third, that WSDL and WSDL 2, despite being the work of really smart people, are so complex and abstract that they have unacceptably poor ease-of-use. What then? Naturally, the mind turns to a smaller, simpler successor, sacrificing generality and eschewing abstraction; in exactly the same way that XML was a successor for SGML. Well anyhow, thats the direction my mind turned. So did Norm Walshs; his proposal for NSDL also includes a helpful explanation of why Web-Service description is important. My sketch is called SMEX-D.

Although the XML geek in me wants this blog post to be a critical analysis of NSDL and SMEX-D, I think a more valuable discussion is questioning the premise behind Tim Bray's post. I agree with his first assumption; web services are important. I also agree with his third assumption that the various flavors of WSDL are too abstract and complex to be of easily useful. More importantly, most of the interoperability problems in the XML Web Service space are usually the fault of WSDL and the XSD type system which it depends on.

However I happen to disagree with his second premise; for Web Services to be useful you need some sort of declaration mechanism. Just to contradict by example, I can point to a wide number of web services such as the Yahoo! Search web services, Flickr web services, del.icio.us web services, 43 Things web services, Bloglines web services and every web site that provides an RSS feed as examples of useful web services that don't use some sort of declarative mechanism to describe the services.

Before deciding to reinvent WSDL, people like Tim Bray and Norm Walsh should ask themselves what purpose a description language like WSDL serves. This is exactly what Mark Nottingham does in his post Questions Leading to a Web Description Format where he writes

A while back, I published a series of entries ( 1 , 2 , 3 , 4 ) about would-be Web Description Formats, with the intent of figuring out which (if any) is suitable, or whether a new one is required.
...

As I said, Ive talked about specific use cases for a Web description format before, but to recap, the big ones are:

Code Generation Its very useful to start with a description of the site, and then code by filling in the blanks. In the Web services world, this is referred to as coding to the contract or contract-first development, and it makes a lot of sense (although I think contract is needlessly legalistic, and misleading too; it implies a closed world, when in reality a description is very open, in that its always subject to additional information being discovered).

A couple of ways that this might manifest is through stub and skeleton generation, and auto-completion and other whizz-bang hinting in tools. Wouldnt it be nice for Eclipse to give you a drop-down of the valid URIs that will give you a certain type when youre coding?

...

Dynamic Configuration Ive complained about the poor state of Web server configuration before, so Ill spare you a repeat of the full polemic. A proper description format would be one mechanism to allow more transparent configuration of servers, and better use of the Web (and HTTP).

...

Application Modeling and Visualisation Finally, theres a considerable amount of value in having a standard representation (thats intentional, folks) of a sites layout and configuration; you can discuss it with peers, evolve it over time in a manner thats independent to the implementation, develop tools to manipulate and visualise it, and so forth.

Looking at this list of benefits of having a description language for web services, I don't see anything that leaps out to me as being a must have. Being able to generate skeleton code from an XML description of a web service is nice but isn't a showstopper. And in the past, the assumptions caused by such toolkits has led to interoperability problems so I'm not enthusiastic about code generation being a good justification for anything in this area.

The dynamic configuration bit is interesting but it is unlikely that we will come up with a description language generic enough to unify formats as diverse as RDDL, RSD, P3P, WSDL, etc that won't be too complex or too simple to be useful.

As for application modelling and visualization, I'm not sure why we need an XML format for that. If someone decides to come up with a dialect of UML for describing web services there doesn't need to be a reason for it to have an XML serialization format except for code generation which as previously stated isn't such a great idea anyway.

For me the question isn't whether we should replace WSDL but rather whether we even needed it in the first place.