See inline ...

Not all Web resources are XML. Are you now attempting to specify that the Web architecture requires that all Web content by available and accessible as XML?

Perhaps, but we can certainly establish this convention as the norm or required. Many SOAP implementations adhere to this convention already. I don't view this as a requirement of the SOAP spec, but as a requirement of the Web services architecture.

I've never made the claim that the current UDDI API is better than other approaches. (I can think of many better mechanisms to perform discovery.) But at the moment, UDDI/discovery isn't under discussion. We're trying to work out basic call semantics and perhaps also description semantics. And I'm also not about to make the claim that SOAP is the best technology. I'm just saying that it works today, and people are using it today, and the XML Protocol working group was chartered to develop an XML Protocol based on SOAP 1.1, and it would behoove us to complete our charter as soon as possible. As I said, starting a new charter to explore a REST-based service invocation mechanism would be a really interesting thing. Trying to change the XML Protocol charter at this late date would be very detremental.

I don't think you get the point. People want to submit a Purchase Order over the Web, and they aren't overly concerned with whether or not it's done using a "safe, side-effect-free operation", they just want to submit the PO. What's the best way to do it? I don't think it's appropriate to do it via GET. You might be able to do it via PUT, but you aren't trying to publish the PO, only submit it. POST seems like the safest, side-effect-free approach.

Please review the charter of the XML Protocol working group. It explicitly says that the XML Protocol should be based on SOAP 1.1 This isn't a request to rubber stamp SOAP 1.1. We want and need to improve SOAP, but we don't want to make a complete change to its architecture. I'm also pointing out some basic realities. W3C is, at heart, an academic organization. And its perfectly reasonable for W3C to pursue its academic goals (REST and the Semantic Web). But if W3C wants to play a major role in business systems, and if W3C wants to continue receiving funding from the big software vendors, then the W3C TAG must be willing to accomodate the requirements of big business. If the REST faction continues to try to undermine the existing Web services architecture, it will alienate big business.

My suggestion is that W3C explore REST in a separate working group. Just don't undermine current business objectives (SOAP-based Web services).

Anne