Aaron reponds to my response to Aaron's response...

In Aaron's latest post in our thread about RNG, he observes that

TCP is an example of a widespread transport that can easily be used with SOAP without significantly impacting overall interoperability potentially. Trying to standardize on some bizarre or proprietary transport would lead to the same issue I see with RNG.

While TCP is a widespread interoperable protocol, there is no widely supported standard for how to send SOAP messages over TCP. Clearly, one will evolve, but the point is that it isn't here now. Some toolkits will support it before others do and there will be interop problems, but they'll be worked out over time.

In short, I don't buy it. A web service toolkit implements a whole range of transport (HTTP, raw TCP, SMTP, etc.), message (XML 1.0, XML 1.1, SOAP 1.1, SOAP 1.2, WS-Security's earlier OASIS draft, WS-Security's later OASIS draft, the original WS-Addressing, the version that went to W3C, etc.) and description (XSD 1.0, WSDL 1.1, the latest round of WS-Policy, WS-SecurityPolicy, etc.) protocols. You get interop if two endpoints can speak the transport, message and descriptive protocols; and are configured to use the same sources of trust for authentication, understand the same message payloads, etc. etc. etc. Over time, as the overall WS protocol suite matures, fewer and fewer interop problems will arise.

If we can move from SOAP 1.1 to SOAP 1.2, or earlier WS-Security specs to later ones, or from SOAP over HTTP to a common approach to SOAP over TCP, then we can move from XSD to RNG. There's no difference, it's just another language that some software understands. If you think otherwise, should we also drop WSDL 2.0? If you support moving to a different, but simpler WSDL, why would you not support moving to a different, but simpler schema language?

All that said, I agree with Aaron's conclusion that a change is unlikely. But his is not the reason why. And, that said, I'll let it go. ;-)