intertwingly

Don Box: Had we started with a simpler basis (perhaps Relax NG + some SOAP-specific extensions), my guess is we'd be having different discussions right now.

I don't.  To me, the keys are the three faces and WS-Get.

Let's explore them in turn, Tim's first.

One World

My experience is that:

• WSDL can describe bindings of operations to many different protocols, but most bindings are to SOAP.
• SOAP can be transported across many different protocols, but most SOAP messages are transported over HTTP.
• Individual SOAP messages may have many different headers, but most don't have any.

Each of the above statements is arguable, but one thing that is undeniable is that a large number of people have found "simple XML over HTTP" to be a sweet spot.

The end result is that people who use a SOAP Toolkit can't access the eBay API.  (example)

I can hear Tim Ewald now "but Soap Envelope and Soap Body are but a small price to pay for future extensibility".  That's nice, but toolkits that insist on inserting these elements don't help those who want to access eBay today.

Now, Imagine a SOAP 1.3 specification which is identical to SOAP 1.2 with exactly two changes:

• If a soap:Envelope is present, then soap:Header is required.
• If you ever want to send a message with zero headers, then you are required to omit the soap:Envelope and soap:Header elements.

In such a world, people who use SOAP 1.3 enabled toolkits would be able to construct messages to be sent to eBay.  If they are so inclined, they could write schemas for such messages (in the schema language of their choice).  They could even wrap this schema in WSDL, and share it amongst themselves.

All of a sudden, a class of developers would find eBay to be "Web Service enabled".  Without requiring any coordination or changes with eBay.

Now, we are in a position to have a different set of discussions.

WS-GET

Now we (almost) get eBay.  What about Bloglines?  These requests require HTTP GET.

Contained in WS-Transfer's description of Get is the following:

There are no body blocks defined for a Get Request.

Above, I talked about omitting soap:Envelope and soap:Body elements when no headers are present, but what should one do if there are no body elements?  How about using HTTP GET in such circumstances?

In fact, for compatibility with WS-Transfer, we could also require the use HTTP GET if there is a single soap:Header which contains a wsa:Action of GET.

All of a sudden, a class of developers would find Bloglines to be "Web Service enabled".  Without requiring any coordination or changes with eBay.

Again, we find ourselves to be in a position to have a different set of discussions.

Other Issues

One of the details I glossed over in the eBay discussions above is that the eBay API also defines some HTTP Headers.  HTTP headers are simple collections of token and string values.  Modeling this as a SOAP Header is a piece of cake.  In fact, there already is one.

There are other details, like status codes, that need to be worked out, but the overall approach is to consider an outside-in instead of the traditional inside-out approach that web services has traditionally taken.

There are a couple of other issues.  Automatically omitting Envelopes will prevent interop with existing SOAP servers.  For this reason, it might make sense to consider this as a WS-HTTP WSDL binding instead of a rev to SOAP itself.

Also, while adding any mustUnderstand will cause existing eBay to crap out, adding any optional headers will cause problems too.  Getting this solved will require a change to eBay, albeit a small one.  There isn't much that can be done to solve this, but allowing soap requests to go out without any envelopes allows progress to be made today, allowing advocacy for soap headers to take place in parallel.