Here we go again!

Mark Baker still doesn't get it.

He writes:

XML is fine and dandy, and I use it whenever I can, but it's just a syntax. As such, it doesn't do anything to alleviate the issue that understanding an XML document is an all-or-nothing proposition. That's why when I use XML, I almost always use RDF. It enables a machine to extract triples from an arbitrary RDF/XML document, and triples are much finer grained pieces of information than a whole document. It allows me to process the triples I understand, and ignore the ones I don't, which
another way of saying that it provides a self-descriptive extensibility model. ...

I don't see it that way. Understanding an XML document is not an all-or-nothing proposition by any stretch of the imagination. For instance, I can have a generic SOAP processor that understands the SOAP namespace but is oblivious to the content of the soap:Body element (amongst other things such as certain SOAP headers). I can write a SOAP header handler that is designed to understand only the header(s) from a specific namespace... It can be oblivious of SOAP headers from other namespaces and need not understand the content of the soap:Body element. Certainly doesn't seem like an all-or-nothing proposition to me. The same applies to any XML vocabulary. Even the example that he cites (use of XML and RDF) proves the statement to be false. An application that extracts RDF triples from an arbitrary XML document certainly doesn't need to know anything about the vocabulary of the containing XML document.

He goes on to say (first quoting Savas, then responding):

If we are going to glue applications/organisations together when building large scale applications, we need to make sure that contracts for the interactions are in place. We need to define message formats. That's what WSDL is all about.

Agreed, but that's also an important part of HTTP. It just defines message formats in a more self-descriptive way (i.e. that doesn't require a separate
description document to understand what the message means).

Not all applications are designed to handle arbitrary message content like a browser or a spider. WSDL is both a contract and a courtesy. By making the WSDL for my service available to potential consumers of my service, I am providing them with (admittedly some, not all of) the information needed to develop an appropriate application interface to my service. Could I do this with an HTML form? Certainly! But the fact of the matter is that these are designed for rendering by a browser and then need someone sitting in front of the browser, applying some intelligence to the questions posed by the form and composing the appropriate responses. This is great for a user interface but not for machine processing by an application.

HTTP is a great application protocol, for the application for which it was designed... the Web.