Still on the road.  More complete response to Jake's weblog entry yesterday.

When doing the SOAP-interop work we did last year, we soapbuilders agreed (at least tacitly) that a SOAP server or client should be as liberal as possible in what it can interpret, and as specific as possible in what it sends.

I agree with this world view.

The more I hear from people working with .NET, the more it seems apparent that it fails to follow the latter guideline -- that it seems to rely on the WSDL to determine how to encode and decode SOAP messages, and that little room is left for variation in the message encoding. This, at the expense of interoperability with software that doesn't (or can't) support WSDL at the same level that .NET does.

This actually has nothing to do with WSDL.  If you call an web service implemented using Apache SOAP 2.x and pass the wrong parameter name as an actual argument, we will be forgiving.  I believe Radio will fail the request.  ASP.Net will ignore the argument passed and invoke the service passing null or zero for the actual argument.

So in this case, the requirement is to make sure that you get the argument names correct in order to ensure maximum interoperability.  This requirement can be met without any reference to any description language.  As can the requirements to encode SOAPAction, namespaces, etc.

Fundamentally, this is a problem with the SOAP specification itself: It's too ambiguous. That's why people want WSDL -- they need more specificity for their SOAP messages.

More specificity in the SOAP protocol itself would have made it much easier to support in a wide variety of programming environments, without having to rely on WSDL.

I disagree.  Apache SOAP 2.x doesn't care about SOAPAction and named parameters.  Radio doesn't appear to care about namespaces and xsi:type.  In order to achieve interoperability, we sometimes need to reach out to one another and provide "extra" information that we don't ourselves require.

WSDL, while it attempts to declare the specific message format, just hasn't been up to the task, because the nature of dynamically-typed programming environments makes WSDL difficult, if not impossible, to support in those environments.

Even producing a WSDL with liberal usage of s:anyType would be a step forward.

  6:33:55 AM