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.

Proposal:
Use a single wrapper.