Counter proposal for Issue 6398

Summary of Counter Proposal

1.      The requirements for BP compliant WSDL are relaxed for WS-Transfer.

2.      All 8 WS-Transfer Messages remain as is, i.e. with no wrapper elements.

3.      All RT messages have their outer wrapper elements removed.

4.      Transfer Create message changes cardinality to 0 or more.

This proposal avoids disrupting the interoperability of existing Transfer implementations by remaining compatible with protocols and formats that depend  on it (see charter), provides an efficient protocol for the 8 key Transfer messages, allows Transfer Create to handle the null constructor case (and offers a smooth migration path from submission to the standard) and changes the RT specification to reference Transfer in an appropriate manner.

Counter Proposal Details

1.      The requirements for BP compliant WSDL are relaxed for WS-Transfer.

Based on the need to create an efficient wire protocol, the WG should agree that those Basic Profile requirements pertaining to the WSDL definition, that prevent such a format being specified, are relaxed for WS-T and WS-RT.  These requirements include: R2202, R2712, R2204 and R9981.  As part of the issue resolution, it should be made clear that BP alignment is made on a case by case basis and that this is a specific relaxation of Basic Profile requirements for this particular purpose and not a general relaxation of all BP requirements, either for this or related specs.

In order for some tools vendors to make progress on this, it may be interesting to consider using Transfer policy assertions to make the offending WSDL sections implicit, rather than explicit, thus eliminating the need to define the WSDL at all.  While this may have other implications, it may be worth discussing this option.

In terms of support for multiple children in the soap body, SOAP 1.2 does support this concept, and many SOAP 1.2 implementations also support it.  Where a soap implementation does not support it, we believe that Transfer can be implemented in a way that conforms to this requirement.

2.      All 8 WS-Transfer Messages remain as is, i.e. with no new wrapper elements added.

There are no changes to the spec required to implement this.

3.      All RT messages have their outer wrapper elements removed.

In order to maintain alignment with the Transfer specification, all outer wrapper elements defined in the RT specification should be removed.  The associated RT messages would now look like:

T-GetRequest:                 RT-GetRequest:

<soap:body>                   <soap:body>
  xs:any *                       <wsrt:Expression Dialect="xs:anyURI" ...> xs:any </wsrt:Expression> *

</soap:body>                  </soap:body>

T-GetResponse:                RT-GetResponse:

<soap:body>                   <soap:body>
  xs:any +                         <wsrt:Result...>xs:any</wsrt:Result> +

</soap:body>                  </soap:body>

T-PutRequest:                 RT-PutRequest:

<soap:body>                   <soap:body>
    xs:any +                       <wsrt:Fragment Dialect="xs:anyURI" ...> +
</soap:body>                  </soap:body>

T-PutResponse:                RT-PutResponse:
<soap:body>                   <soap:body>
  xs:any ?                       xs:any ?
</soap:body>                  </soap:body>


T-DeleteRequest:
<soap:body>
  xs:any *
</soap:body>

T-DeleteResponse:
<soap:body>
  xs:any *
</soap:body>


T-CreateRequest:              RT-CreateRequest:
<soap:body>                   <soap:body>

  xs:any *                       <wsmex:Metadata ...> ?
                                 <wsrt:Fragment ...> *
</soap:body>                  </soap:body>

T-CreateResponse:             RT-CreateResponse:
<soap:body>                   <soap:body>
  <wst:ResourceCreated>         <wst:ResourceCreated>
    xs:any ?                      xs:any ?
  </wst:ResourceCreated>        </wst:ResourceCreated>

  xs:any *                      xs:any *

</soap:body>                  </soap:body>

4.      Transfer Create message changes cardinality to 0 or more.

In order to support the case of a null constructor, the Transfer Create message in the schema should be changed from

xs:any +

To

xs:any *

The charter states that WS-Transfer should remain compatible with protocols that depend on it, and offer a smooth migration path.  This can be achieved here in that if original implementations which do not support a zero element create would simply fault (t:InvalidRepresentation) anyway.  We should suggest in the migration instructions that this fault should continue to be used if the implemented code does not support null create messages.

--Geoff