Re: issue 6398: updated proposal - HTTP Linkage

Hi Geoff:
The questions we are likely to be asked are along the lines: if there is 
a URI in the EPR what happens if I do URI-like things to it such GET? 
What is returned?
I'm still thinking about how to approach this.
All the best, Ashok


Geoff Bullen wrote:
>
> Gil,
>
> More than other specifications, Transfer should continue to be aligned 
> with HTTP. Wrappers represent one area we can look at in order to 
> achieve that goal. looking at RFC 2616, we note that it uses some 
> specific terms to refer to what Doug might be calling a wrapper.
>
> Some possibilities we found we:
>
> body
>
> entity-body
>
> message-body
>
> Ashok, do you think that the TAG would find the use of any of these 
> terms as the wrapper for all 8 Transfer messages as further indication 
> of the alignment between Transfer and HTTP? Is there another wrapper 
> name that would be more aligned?
>
> --Geoff
>
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Thursday, February 05, 2009 10:38 PM
> *To:* Geoff Bullen
> *Cc:* Doug Davis; public-ws-resource-access@w3.org
> *Subject:* Re: issue 6398: updated proposal - HTTP Linkage
>
> Geoff,
>
> Let me see if I understand your objections. You are saying (and 
> correct me if I am wrong) that, because Doug chose to name his wrapper 
> elements things like "wst:Get" and "wst:Put", this implies that these 
> wrappers will or should be regarded as verbs. Would it make any 
> difference if we called them "wst:Foo", "wst:FooResponse", "wst:Baz", 
> "wst:BazResponse", etc.?
>
> - gp
>
> Geoff Bullen wrote:
>
> Doug,
>
> Transfer and HTTP are already linked to some extent, I think we agree 
> on that, and from the number of emails going around concerning this 
> linkage, I suspect it is certainly one we need to look at more closely.
>
> One of the ways in which Transfer and HTTP are currently linked, is 
> that they share a common model.
>
> As stated in an earlier email, the HTTP message body carries the 
> content (or message body) and not the verb (action). In the same way, 
> the Transfer SOAP body carries the content and not the action. In both 
> cases, the action is handled separated from the message body.
>
> Now let’s look at your current wrapper proposal.
>
> While you call it a “wrapper” proposal, the names you use for those 
> wrapper elements are the same as the names of the associated actions 
> (verbs). For example:
>
> The action: “http://.../transfer/GetResponse” directly maps to a corresponding outer element in the body:
>
> wst:GetResponse ...>
> xs:any +
>
> </wst:GetResponse>
>
> This is the pattern that is used throughout your wrapper proposal.
>
> Stating the obvious, there appears to be a direct correlation between 
> the action name and the name of the outer element of the soap body (in 
> this case “GetResponse”). Whether implied or intentional, this 
> correlation breaks the basic model of separation (of verb and content) 
> described earlier. Note that it also violates the basic premise of 
> addressing, that wsa:action is what is used to differentiate messages.
>
> --Geoff
>
> *From:* public-ws-resource-access-request@w3.org 
> <mailto:public-ws-resource-access-request@w3.org> 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Doug 
> Davis
> *Sent:* Wednesday, February 04, 2009 3:01 PM
> *To:* public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>
> *Subject:* RE: issue 6398: updated proposal
>
>
> To follow-up on the conf call yesterday....
>
> Geoff mentioned the Team Comments on WS-Transfer [1] as an implicit 
> endorsement of the supposed alignment between HTTP and WS-Transfer. 
> However, I think this is not the case:
> - the team comments do not actually say that the "parallel" between 
> HTTP and WS-Transfer is a good thing it just points out that both have 
> similar verbs/operations.
> - in fact, after this similarity is pointed out the comments go on to 
> say how misaligned WS-Transfer is with the Web due to the use of EPRs 
> instead of URIs. It says things like WS-Transfer resources could be 
> "...unsuitable for referencing and use in other Web technologies".
> - add to this Tim's comments [2], as Bob pointed out on the call, that 
> there is a concern over WS-Transfer's lack of alignment with HTTP 
> around such things as its use (or lack of use) of HTTP GET. Its worth 
> noting that Tim reiterates the concern about the misalignment of 
> WS-Transfer with the Web itself because of its use of EPRs.
> - also, no where in the team comments do they make any reference to 
> the notion that because the Body is 'unwrapped' its more aligned with 
> HTTP. It doesn't even touch on this subject at all. And, as I pointed 
> out on the call, this would be a mistake for them to even head down 
> this path because there are lots of cases where the HTTP Body is 
> wrapped (like mime-encoding) and those are clearly not misaligned with 
> HTTP.
>
> I do agree with Geoff that the alignment of WS-Transfer with HTTP, and 
> the Web itself, should be more closely examined - especially given the 
> Team/Tag/Tim comments - but this is a separate issue that has nothing 
> to do with whether the Transfer operations include a wrapper in the 
> Body or not.
>
> [1] http://www.w3.org/Submission/2006/04/Comment
> [2] http://lists.w3.org/Archives/Public/www-tag/2006Oct/0061.html
>
> thanks
> -Doug
> ______________________________________________________
> STSM | Standards Architect | IBM Software Group
> (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com <mailto:dug@us.ibm.com>
>
>
> *Geoff Bullen <Geoff.Bullen@microsoft.com> 
> <mailto:Geoff.Bullen@microsoft.com>*
> Sent by: public-ws-resource-access-request@w3.org 
> <mailto:public-ws-resource-access-request@w3.org>
>
> 02/03/2009 12:35 PM
>
> 	
>
> To
>
> 	
>
> Doug Davis/Raleigh/IBM@IBMUS
>
> cc
>
> 	
>
> "public-ws-resource-access@w3.org" 
> <mailto:public-ws-resource-access@w3.org> 
> <public-ws-resource-access@w3.org> 
> <mailto:public-ws-resource-access@w3.org>
>
> Subject
>
> 	
>
> RE: issue 6398: updated proposal
>
>
> 	
>
>
>
>
> Hi Doug,
> Having re-read our previous email a couple of times, it is still kind 
> of unclear exactly what you think we are in agreement on here. J While 
> it is hopeful we will find common ground at some point, we are not 
> there yet.
>
> Regarding Transfer Create Operation …
>
> T.Create and RT.Create currently have different cardinalities and one 
> of them therefore must change in order for them to remain “in sync”.
>
> The current version of T.Create() states that the first child element 
> MUST NOT be omitted. But the draft proposal allows senders to emit 
> empty Create requests. This means, current Transfer Resource Factories 
> cannot process the proposed Create request messages without changing 
> the underlying processing logic.
>
> Cheers,
> Geoff
>
>
>
> *From:* Doug Davis [mailto:dug@us.ibm.com] *
> Sent:* Monday, February 02, 2009 5:27 PM*
> To:* Geoff Bullen*
> Cc:* public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>*
> Subject:* RE: issue 6398: updated proposal
>
>
> Geoff,
> thanks for the comments. I'm glad that we're in agreement that there 
> is no functional difference between what the current version of 
> Transfer and my proposal because I tried to ensure that it was just a 
> syntax change. As to the change of cardinality of Create, I was very 
> clear as to why I changed it - please reread my proposal. Also, it 
> does not break backwards compatibility - aside from the addition of a 
> wrapper, existing impls will still be sending valid WS-T messages.
>
> thanks
> -Doug
> ______________________________________________________
> STSM | Standards Architect | IBM Software Group
> (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com <mailto:dug@us.ibm.com>
>
> *Geoff Bullen <Geoff.Bullen@microsoft.com> 
> <mailto:Geoff.Bullen@microsoft.com>*
>
> 02/02/2009 07:32 PM
>
> 	
>
> To
>
> 	
>
> Doug Davis/Raleigh/IBM@IBMUS
>
> cc
>
> 	
>
> "public-ws-resource-access@w3.org" 
> <mailto:public-ws-resource-access@w3.org> 
> <public-ws-resource-access@w3.org> 
> <mailto:public-ws-resource-access@w3.org>
>
> Subject
>
> 	
>
> RE: issue 6398: updated proposal
>
>
>
> 	
>
>
>
>
>
> Doug,
> We have been looking more closely at the wrapper issue (Issue 6398) 
> and your current proposal and there are a number of concerns that we have.
>
> Summary
> We believe that the proposed changes will affect the current alignment 
> of Transfer with HTTP, and that it breaks the current implementation 
> of Transfer by changing the cardinality of message formats. More 
> specific details can be seen below:
>
> 1) Wrappers and the Alignment of Transfer with HTTP
> We believe that the proposed wrapper changes disrupt the current 
> alignment between Transfer and HTTP. Since the TAG articulated in Nov, 
> 2008 that they were interested in a closer alignment between Transfer 
> and HTTP, it is unclear to us if this is the right direction for the 
> WG to be heading.
>
> There are a set of principles that guide us as we move through this issue:
> a) Transfer continues to have alignment with HTTP as much as possible.
> b) Transfer is built on WS-A and honors the WS-A action based dispatch 
> model.
> c) Transfer should be aligned with Basic Profile as much as possible.
>
> With regards to goal a) above, the HTTP message body carries the 
> content (or message body) and not the verb (action). In the same way, 
> the Transfer SOAP body carries the content and not the action. We 
> believe using specific wrapper element names, such as <get> and 
> <getresponse>, implies there is semantic meaning in those names, which 
> affects the separation described above and thus disrupts the existing 
> alignment between Transfer and HTTP. Any semantic meaning also goes 
> against goal b).
>
> Also with regards to goal a), the WG has not yet received any 
> technical comments from the TAG nor has the TAG articulated its wishes 
> clearly to us. Shouldn't we engage the TAG ASAP?
>
>
> 2) Wrappers, Cardinality and the Create verb
> While you expressed a desire to treat cardinality as separate from the 
> wrapper issue, your proposal does in fact change the cardinality of 
> the Transfer messages, Delete and Create. While changing the 
> cardinality of T.delete does not break backwards compatibility, 
> changing the cardinality of T.create certainly does. It is unclear to 
> us why your proposal has chosen to break backwards compatibility with 
> T implementations. It is our understanding that there are many current 
> interoperable implementations of the T spec, so would not it be more 
> prudent to align more closely with the current version of T?
>
> --Geoff
>
>
> From: public-ws-resource-access-request@w3.org 
> <mailto:public-ws-resource-access-request@w3.org> 
> [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
> Sent: Sunday, January 18, 2009 10:34 AM
> To: public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>
> Subject: RE: issue 6398: updated proposal
>
>
> Hey Geoff,
> thanks for the heads up on the cardinality - I'll double check those - 
> but what's correct depends on whether you're looking at the schema or 
> the text of the spec. For example, GetResponse, per the pseudo schema 
> should be as you noted (+), but per the schema it should be a 
> singleton. Either way - this is our chance to make sure things are 
> aligned. As for the MEX change, despite some possible ribbing from 
> Jeff :-), I like consistency - so if you open an issue I wouldn't object.
>
> 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 <mailto:dug@us.ibm.com>
>
> Geoff Bullen <Geoff.Bullen@microsoft.com> 
> <mailto:Geoff.Bullen@microsoft.com>
> Sent by: public-ws-resource-access-request@w3.org 
> <mailto: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" 
> <mailto:public-ws-resource-access@w3.org> 
> <public-ws-resource-access@w3.org> 
> <mailto: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> 
> [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 
> <mailto: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.
>
> thanks
> -Doug
> ______________________________________________________
> STSM | Web Services Architect | IBM Software Group
> (919) 254-6905 | IBM T/L 444-6905 | dug@us.ibm.com 
> <mailto:dug@us.ibm.com>
>

Received on Sunday, 8 February 2009 21:19:32 UTC