Re: Counter proposal for Issue 6398

Geoff

We need to be clear here:  The WS-Transfer specification that emerges as a 
W3C REC spec will have a new namespace.   All bets for interoperability 
with existing implementations are off - it is essentially a new 
specification. 
The charter states:
"...In order to avoid disrupting the interoperability of existing 
implementations, WS-MetadataExchange, WS-Transfer, WS-Eventing and 
WS-Enumeration should remain compatible with protocols and formats that 
depend on them..."
This is not the same as saying that existing implementations will 
automatically interop with the W3C REC specs.  The interoperability of 
existing implementations will not be disrupted by the addition of wrapper 
elements to the W3C REC specification. 

Relaxing the BP compliance for WS-Transfer is simply not an option because 
BP-compliant tooling across the industry will not be able to consume/gen 
the WS-Transfer WSDL.   Lack of BP compliance will therefore restrict the 
adoption of this spec.
<gb>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.</gb>
You're right that this may be 'interesting' :o)  but it would be jumping 
through unnecessary hoops in order to avoid the far simpler solution.

Regards,
Katy



From:
Geoff Bullen <Geoff.Bullen@microsoft.com>
To:
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, 
"public-ws-resource-access-request@w3.org" 
<public-ws-resource-access-request@w3.org>
Date:
24/02/2009 03:40
Subject:
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
 







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU