This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6398 - Transfer-WS-Transfer violates WS-I BP w.r.t. the use of types
Summary: Transfer-WS-Transfer violates WS-I BP w.r.t. the use of types
Status: CLOSED REMIND
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Transfer (show other bugs)
Version: FPWD
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Doug Davis
QA Contact: notifications mailing list for WS Resource Access
URL: http://lists.w3.org/Archives/Public/p...
Whiteboard:
Keywords: migrationPathNeeded
Depends on:
Blocks: 6413 6500 6594
  Show dependency treegraph
 
Reported: 2009-01-14 00:02 UTC by Doug Davis
Modified: 2009-04-21 21:23 UTC (History)
1 user (show)

See Also:


Attachments

Description Doug Davis 2009-01-14 00:02:56 UTC
The WS-I Basic Profile has the following requirement: 
R2712 A document-literal binding MUST be serialized as an ENVELOPE with a 
soap:Body whose child element is an instance of the global element 
declaration referenced by the corresponding wsdl:message part. 

In short, this means that when the WSDL contains elements such as: 
<wsdl:part name="Body" type="tns:AnyXmlType"/> 
when document-literal binding is used, which we do use, this is in 
violation of the BP.  The "type='...'" needs to be element='...' where 
'...' is replaced by some GED (global element declaration). 

WS-Transfer does this on the GetRequest, GetResponse, PutRequest, 
PutResponse, DeleteResponse and CreateRequest messages. 

Proposal:
Replace the use of 'type's with a well defined GED (wrapper) that has the 
'type' as a child. For example:

  <wsdl:message name="OptionalXmlMessage">
    <wsdl:part name="Body" type="tns:AnyXmlOptionalType"/>
  </wsdl:message>
  <wsdl:message name="AnyXmlMessage">
    <wsdl:part name="Body" type="tns:AnyXmlType"/>
  </wsdl:message>
  <wsdl:operation name="Get">
    <wsdl:input 
      message="tns:OptionalXmlMessage"
      wsa:Action="http://schemas.xmlsoap.org/ws/2004/09/transfer/Get"/>
    <wsdl:output 
      message="tns:AnyXmlMessage"
      wsa:Action="
http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse" />
  </wsdl:operation>

gets replaced with:

  <xs:element name='Get'>
    <xs:complexType>
      <xs:sequence>
        <xs:any minOccurs='0' maxOccurs='1' processContents='skip' 
namespace='##other' />
      </xs:sequence>
    </xs:complexType>
  </xs:element> 
  <xs:element name='GetResponse'>
    <xs:complexType>
      <xs:sequence>
        <xs:any minOccurs='1' maxOccurs='1' processContents='skip' 
namespace='##other' />
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <wsdl:message name="GetRequestMessage">
    <wsdl:part name="Body" element="tns:Get"/>
  </wsdl:message>
  <wsdl:message name="GetResponseMessage">
    <wsdl:part name="Body" element="tns:GetResponse"/>
  </wsdl:message>
  <wsdl:operation name="Get">
    <wsdl:input 
      message="tns:GetRequestMessage"
      wsa:Action="http://schemas.xmlsoap.org/ws/2004/09/transfer/Get"/>
    <wsdl:output 
      message="tns:GetResponseMessage"
      wsa:Action="
http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse" />
  </wsdl:operation>

So the resulting XML on the wire would look like:
Request Body:
<env:Body>
  <wst:Get>
    ...
  </wst:Get>
</env:Body>

Response Body:
<env:Body>
  <wst:GetResponse>
    ...
  </wst:GetResponse>
</env:Body>

The pseudo schema for each would be:
GetRequest:
<wst:Get>
  xs:any ?
</wst:Get>

GetResponse:
<wst:GetResponse>
  xs:any
</wst:GetResponse>

PutRequest:
<wst:PutRequest>
  xs:any
</wst:PutRequest>

PutResponse:
<wst:PutResponse>
  xs:any ?
</wst:PutResponse>

DeleteResponse:
<wst:DeleteResponse>
  xs:any ?
</wst:DeleteResponse>

CreateRequest:
<wst:CreateRequest>
  xs:any
</wst:CreateRequest>
Comment 1 Robert Freund 2009-01-20 21:30:09 UTC
proposal from http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jan/0043.html

All,
  below is a modified version of the proposal, showing the pseudo schema 
changes to T and RT (some of the cardinalities will vary slightly from 
previous proposal and from the specs in an effort to ensure things are 
consistent and allow for RT to do its job) - I tried to make a note of 
each one as I detected it (hopefully the following shows up ok for 
everyone - if not let me know and I'll put it into a separate file):

T-GetRequest:                 RT-GetRequest:
<wst:Get ... >                <wst:Get Dialect="xs:anyURI" ...>
 xs:any *                       <wsrt:Expression ...> xs:any 
</wsrt:Expression> *
</wst:Get>                    </wst:Get>
Note: to allow for more than one Expression, I had to change the 'xs:any 
?' to a "xs:any *" on the xs:any of the T.Get(), and for full 
extensibility (an attribute on Get could make the need for children 
unnecessary).

T-GetResponse:                RT-GetResponse:
<wst:GetResponse ...>         <wst:GetResponse ...>
 xs:any +                         <wsrt:Result...>xs:any</wsrt:Result> +
</wst:GetResponse>            </wst:GetResponce>
Note: We should consider changing the "xs:any +" to "xs:any *" since the 
resource representation could technically be empty and we should allow for 
that (<wsrt:Result>+ too), and for full extensibility (an attribute on 
GetResponse could make the need for children unnecessary).

T-PutRequest:                 RT-PutRequest:
<wst:Put ...>                 <wst:Put Dialect="xs:anyURI" ...>
 xs:any +                       <wsrt:Fragment ...> +
</wst:Put>                    <wst:Put>
Note: We should change "xs:any +" to "xs:any *" to allow for an empty 
represenation to be 'put', and for full extensibility (an attribute on Put 
could make the need for children unnecessary).

T-PutResponse:                RT-PutResponse:
<wst:PutResponse ...>         <wst:PutResponse ...>
 xs:any ?                       xs:any ?
</wst:PutResponse>            </wst:PutResponse>
Note: We should change the "xs:any ?" to "xs:any *" to allow for full 
extensbility.

T-DeleteRequest:              RT-DeleteRequest:
<wst:Delete ...>              <wst:Delete ...>
  xs:any *                      xs:any *
</wst:Delete>                 </wst:Delete>
Note: I added the "xs:any *" extensibility point in here.

T-DeleteResponse:             RT-DeleteResponse:
<wst:DeleteResponse ...>      <wst:DeleteResponse>
 xs:any ?                       xs:any ?
</wst:DeleteResponse>         </wst:DeleteResponse>
Note: We should change the "xs:any ?" to "xs:any *" to allow for full 
extensbility.

T-CreateRequest:              RT-CreateRequest:
<wst:Create ...>              <wst:Create Dialect="xs:anyURI" ...>
 xs:any *                       <wsmex:Metadata ...> ?
                                <wsrt:Fragment ...> *
</wst:CreateRequest>          </wst:CreateRequest>
Note: I changed the "xs:any +" to "xs:any *" for three reasons: 1) it 
seems like it should be possible to allow the entire resource to have 
default values, 2) per the RT spec the mex and fragment elements are 
optional, 3) to allow for full extensibility (an attribute on the Create 
could make up for the absence of child elements).

T-CreateResponse:             RT-CreateResponse:
<wst:CreateResponse ...>      <wst:CreateResponse ...>
  <wst:ResourceCreated>         <wst:ResourceCreated>
  xs:any ?                      xs:any ?
</wst:CreateResponse>         </wst:CreateResponse>
Note: We should change the "xs:any ?" to "xs:any *" to allow for full 
extensbility.

We should discuss the "xs:any ?" -> "xs:any *" notes I made - if there 
isn't any objection we can include it as part of this.

thanks
-Doug
______________________________________________________
STSM  |  Web Services Architect  |  IBM Software Group
(919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com



Geoff Bullen <Geoff.Bullen@microsoft.com> 
Sent by: public-ws-resource-access-request@w3.org
01/16/2009 12:09 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
RE: issue 6398: updated proposal






Doug,
A couple of things:
1)      I believe the ?xs:any? defined in GetResponse, PutRequest, 
CreateRequest should actually be ?xs:any +? defining  one or more.
2)      I am wondering if, for the sake of consistency and extensibility, 
we should also be looking at the GetMetadata Request and Response messages 
in MEX and adding a similar outer wrappers and extensibility concepts?
Thoughts?
--Geoff
 
From: public-ws-resource-access-request@w3.org 
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Thursday, January 15, 2009 6:36 AM
To: public-ws-resource-access@w3.org
Subject: issue 6398: updated proposal
 

per my AI from yesterday, the updated pseudo schema for the wrapped 
WS-Transfer operations would be: 

GetRequest:
<wst:Get ... >
 xs:any ?
</wst:Get>

GetResponse:
<wst:GetResponse ...>
 xs:any
</wst:GetResponse>

PutRequest:
<wst:PutRequest ...>
 xs:any
</wst:PutRequest>

PutResponse:
<wst:PutResponse ...>
 xs:any ?
</wst:PutResponse>

DeleteResponse:
<wst:DeleteResponse ...>
 xs:any ?
</wst:DeleteResponse>

CreateRequest:
<wst:CreateRequest ...>
 xs:any
</wst:CreateRequest> 

CreateResponse: 
<wst:CreateResponse ...> 
  <wxf:ResourceCreated>endpoint-reference</wxf:ResourceCreated> 
  xs:any ?   
</wst:CreateResponse> 

In looking at how this impacts RT... it shouldn't. RT overrides T's Body 
(in some cases already using a wrapper similar to the above) so that can 
continue as is. The only thing missing from the previous proposal was the 
extensibilty points on the wrapper elements so that attributes could be 
added - but that was a typo :-) .  Existing RT can continue to override 
the the above messages with a well defined element - this, along with the 
RT header allows the receiver to know this isn't a normal/vanilla Transfer 
operation. 

There is no impact on MEX.  I couldn't find any reference to the transfer 
operations that needed to be changed - no samples using it either. 
Comment 2 Robert Freund 2009-02-11 07:56:32 UTC
Pending Action-14
Comment 3 Robert Freund 2009-03-03 12:05:28 UTC
resolved on 2009-02-24 with proposal contained in comment #1