Peter Drayton points to A Comparison of Alternative Encoding Mechanisms for Web Services which has a comparison of XMill and other compression techniques used in a web service context. I've tended to discount XMill, and many other compression oriented solutions, in this context because there doesn't seem to be a reasonable way to implement them over a stream of XML. Having to buffer every message puts a lot more memory pressure on a server and that should impact throughput.

However, I didn't see evidence of this in my first (brief) reading of the cited paper. This may be because using just two computers (a client and a server) is not a configuration where memory pressure would be significant. If the server were handling 1000 simultaneous requests from 1000 different clients, I expect it would be quite noticeable.

Also, many current SOAP implementations buffer anyway, mostly because of the interaction between SOAP Faults and HTTP status codes, but this will not be the case as A) SOAP directly over TCP/IP becomes the norm (at least I think it should become the norm); and B) intermediaries become part of many web service designs.

Simon Fell: If you're going to provide section 5 support, then do it, if you don't like section 5, then don't support it, but providing a subset just confuses the issue.

While I won't encourage selective implemenation of standards, I do think there is an interesting point to be made here. To my knowledge, no implementation really supports everything in SOAP and WSDL. You get a venn diagram of features. I assert that the features in the center are the only ones that are really useful. I don't mean they are useful only because everyone implements them, but that everyone implements them because they are useful. It is technological evolution in practice.

(Can you belive there is a http://www.venndiagram.com!)

Simon Fell says "in my experience the MSTK is significantly more compliant with the specs than ASP.NET web services."

I have to agree with Keith. Interoperability tests show that the STK and ASP.Net have more or less the same level of interoperability. To my knowledge, no SOAP/WSDL implementation is 100% complete.

Of the features listed by Keith and Simon, the STK doesn't support sparse arrays or partial arrays. Multi-dinensional arrays are supported only if you know how to edit the WSDL we generate (meaning that about 2 people on earth can do it reliably). The root attribute and hexBinary were just added in the 3.0 release. (What is the point of hexBinary anyway?). We do ignore mustUnderstand="1" when the actor is specified and has a value of any URI other then "http://schemas.xmlsoap.org/soap/actor/next" (but the SOAP 1.1 specification is ambiguous on this issue). I'm not sure what Simon ment by "certain kinds of Generic Compound Types."