- From: Geoff Bullen <Geoff.Bullen@microsoft.com>
- Date: Tue, 10 Feb 2009 12:14:28 -0800
- To: Doug Davis <dug@us.ibm.com>
- CC: Gilbert Pilz <gilbert.pilz@oracle.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <5AAAA6322448AA41840FC4563A30D6E8439955C2FA@NA-EXMSG-C122.redmond.corp.microsoft>
Doug,
Can we up-level a bit for a moment here.
>From what we understand, the WS-Transfer protocol was originally designed to be aligned with HTTP, and currently still is. You can even see this in the names: Web Service Transfer Protocol - Hypertext Transfer Protocol. Basically, Transfer was designed to be HTTP over SOAP over any SOAP binding. This alignment with HTTP can also be seen in the use of the same verbs and the separation of verb and message body. Currently the verbs are defined as wsa actions in the soap header and the message body used in Transfer is delineated by <soap:body>. Note that <soap:body> is used for all messages and carries no message specific meaning or semantics.
If we now look at the current proposal:
Firstly, we note that there appears to be little real value to these wrappers, in that they add no semantic meaning and do not aid in parsing the message. Basically we appear to be changing:
<soap:body> ... <\soap:body> into
<soap:body> <wrapper> ... <\wrapper><\soap:body>
The reason we seem to be doing this is to support BP 1.1 - as noted in the subject of the Issue.
>From our understanding, Basic Profile 1.1 was defined in a time before Addressing was defined and so there were no action verbs. In order to solve this problem an outer element surrounding all soap body messages was defined. This outer element had semantic meaning - it was the verb and was used to differentiate between soap messages. Each name had to be unique so that it could be used to dispatch the messages correctly. This is the reason the outer element was created.
If we were to follow Basic Profile 1.1 exactly, then each of the outer elements (in this proposal called "wrappers") would have to have a unique name, so they could be used for dispatch as stated above. This is what the proposal does.
So what is the value of this wrapper now that addressing has been standardized in W3C?
Does it really still aid interop? (the original reason for the existence of BP 1.1)
Surely that is only possible if the outer element name was still used as a verb instead of using Addressing actions?
So it would seem that Transfer is designed to separate the verb from the message, and BP 1.1 is designed to put the verb in the message.
Re-iterating the three principles outlined in an earlier email:
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.
There is currently an open action item for Ashok to reach out to the TAG and understand their real thoughts and goals around this issue. We hope to hear from them soon.
--Geoff
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Sunday, February 08, 2009 1:29 PM
To: Geoff Bullen
Cc: Gilbert Pilz; public-ws-resource-access@w3.org
Subject: RE: issue 6398: updated proposal - HTTP Linkage
Geoff,
this raises some interesting questions, points and possibilities.
1 - can you show me where this alignment of HTTP and Transfer is viewed by the W3C Team/Tag as good thing? As I've stated before, the team comments [1] talk about a "parallel" between the two but that is not the same thing as a statement of love. In fact, the rest of the team comments, and Tim's comments [2] could be interpreted as the exact opposite. The sharing of similar verbs is not enough to "align" the two. IMO, the key quote is (bolding is mine):
...which means that WS-Transfer resources are potentially identified by more than just a URI, making them unsuitable for referencing and use in other Web technologies
I'm having a hard time thinking of another WS spec that has caused more tension between the Web/HTTP and SOAP worlds - aside from perhaps WS-Addressing - and Transfer seems to have all of those same criticisms plus more.
2 - you seem to be really straining hard to avoid using meaningful XML elements in the Body. Can you please explain why? Most WS specs have element names in the Body that are not meaningless and in fact you yourself opened an issue for MEX to follow this same pattern [3]. Why should WS-Transfer be different from the other WS specs? I feel like there's something deeper here and you're not letting us in on the secret. Especially when in the note below you now seem to be ok with a wrapper - but you want it to have an HTTP-based meaning.
3 - you assert that "More than other specifications, Transfer should continue to be aligned with HTTP", I actually very strongly disagree with this. Web Services are transport agnostic and any attempt to make it favor one transport over another should not be allowed.
4 - WS-Transfer is, first and foremost, a SOAP specification. Given a choice between aligning with HTTP and the rest of the SOAP specifications/stacks, I'd choose the latter.
5 - having said that, your insistence that WS-Transfer be aligned with HTTP is an interesting perspective and one that I think we need to consider further - especially given the W3C's concerns about its lack of alignment with the Web itself. I think in the interest of trying to address the W3C concerns (and this alignment you seem to see), I would suggest that we consider having WS-Transfer profile its use of WS-Addressing so that it bans the use of reference-parameters for identification purposes - in all transports. (We may even want to consider banning their use entirely just to really force the issue). And we then make a formal requirement that a "naked HTTP GET" to the wsa:Address of a WS-Transfer resource's EPR be the semantic equivalent of a WS-Transfer.Get to that same resource. This requirement will ensure two things: 1) people aren't ignoring the "no ref-params for identification purposes" rule, and 2) address the W3C's concern about whether WS-Transfer resources will play nicely with the rest of the Web technologies. IMO, this will go a lot further to align HTTP and WS-Transfer than worrying about the name of an XML wrapper.
[1] http://www.w3.org/Submission/2006/04/Comment
[2] http://lists.w3.org/Archives/Public/www-tag/2006Oct/0061.html
[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=6500
thanks
-Doug
______________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
Geoff Bullen <Geoff.Bullen@microsoft.com>
02/08/2009 01:03 PM
To
Gilbert Pilz <gilbert.pilz@oracle.com>
cc
Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
RE: issue 6398: updated proposal - HTTP Linkage
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<http://>" 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. :) 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 Tuesday, 10 February 2009 20:15:22 UTC