Formal Objection: Separation of Verb from Content

A vote took place during the WS-RA conference call held on Feb 24, 2009 in order to resolve Issue 6398 [1].  Microsoft believes that alternatives were still available and that the working group should have continued to seek consensus.



This objection focuses on one issue: the decision to define multiple wrapper elements, rather than a single wrapper element.  This decision undermines the WS-Addressing specification.  We believe that the purposes of the working group could have been achieved with a single wrapper element, and that it was wrong to cut off debate without seriously considering that option.



Background and details:



The submitted version of WS-Transfer allows the body element of a SOAP message to directly contain a resource representation.  Some members of the working group strongly desired to insert a wrapper element around the resource representation so that WSDL descriptions of such messages would conform to WS-I Basic Profiles.



This could have been achieved by defining a single wrapper element, having the same element name regardless of which WS-Transfer message it would appear in.  However, the working group defined multiple wrapper elements, such that each WS-Transfer action (as expressed in the wsa:Action header) would correspond uniquely to a distinct wrapper element.



Having multiple, distinguished wrapper elements encourages fracturing of the web services community around two different and non-interoperable implementation choices.  Here is why:



Historically, before WS-Addressing [2] became a standard, many web service implementations used the first child element of the SOAP body in order to determine which operation to invoke.  The first child element name effectively became the "verb" used to route web service messages.  WS-Addressing standardized "action" semantics in the SOAP header (using the action URI) to achieve this goal and thus required no semantics at all in the SOAP body.  This action URI became the new way to define the verb, and also aligned with the principles used in HTTP [3] (i.e. that the HTTP body should contain content, not dispatch information).



WS-Transfer [4] contains a normative reference to WS-Addressing, and is designed around the dispatch of messages using the action URI.



The decision here, to require that the name of the first child element match the action, makes ambiguous the role of the first child element in defining the verb used for routing messages.  Implementers could incorrectly dispatch using the first child element as the verb, rather than support the WS-Addressing action as the verb.  Replication of information always decreases interoperability, and this continued polarization has to stop if interoperability is to be achieved.  This interoperability issue is real, not just hypothetical.



We also want to point out that there were a number of comments on the table around which consensus proposals might have been generated.  These include a comment suggesting the use of a single wrapper name irrespective of the operation, which was been mentioned by IBM [5].  The appropriate excerpt from this email is included below, with the relevant text embedded  between "***"  for clarity:



<quote>

If you are intent in preserving alignment of WS-T with HTTP, then WS-T needs to support the REST uniform interface constraint that informed the design of HTTP. To do this, the  description of the interface (if it is to be conformant with the WS-I  profiles) *** must be designed such that there is a (single, defined) element definition bound to the response. ***

</quote>



We feel it is the role of every W3C WG to both improve interoperability and support W3C recommendations and we believe that this decision, instead, potentially fractures interoperability and does not encourage alignment with the action URI defined in WS-Addressing.  We therefore object to the current resolution of this issue.



Best Regards,

Geoff Bullen

Microsoft Corporation



[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=6398

[2] http://www.w3.org/TR/ws-addr-core/

[3] http://www.ietf.org/rfc/rfc2616.txt

[4] http://www.w3.org/Submission/WS-Transfer/

[5] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0077.html