- From: Geoff Bullen <Geoff.Bullen@microsoft.com>
- Date: Fri, 6 Feb 2009 07:45:16 -0800
- To: Doug Davis <dug@us.ibm.com>
- CC: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <5AAAA6322448AA41840FC4563A30D6E8427CB3EDBF@NA-EXMSG-C122.redmond.corp.microsoft>
Doug,
At least we agree that this change actually does break backwards compatibility for Transfer.
Note that there are also a number of other specifications that currently reference Transfer, and while a namespace change obviously creates a breaking change, it does not, in of itself, change the processing model (i.e. application code). This change, however, does affect the processing model.
The charter states:
In order to avoid disrupting the interoperability of existing implementations, WS-MetadataExchange<http://www.w3.org/Submission/2008/SUBM-WS-MetadataExchange-20080813/>, WS-Transfer<http://www.w3.org/Submission/2006/SUBM-WS-Transfer-20060927/>, WS-Eventing<http://www.w3.org/Submission/2006/SUBM-WS-Eventing-20060315/> and WS-Enumeration<http://www.w3.org/Submission/2006/SUBM-WS-Enumeration-20060315/> should remain compatible with protocols and formats that depend on them, and offer a smooth migration path from the submission to the standard.
It is important for the WG to consider this in the light of your change proposal. In order to maintain or increase the adoption rate of Transfer when it becomes a W3C Recommendation, it is in the Working Group's best interest to minimize disruptive changes as we address issues.
--Geoff
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, February 03, 2009 12:18 PM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: issue 6398: updated proposal
Geoff wrote:
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.
I think we need to move past the notion that existing implementations will not need to change - if nothing else the namespace issue will force that - so let's just put the nail in that coffin. To this specific case, if an implementation does not support having default values for the entire representation then it's free to fault an empty Create. Just like its free to fault a non-empty Create for any number of reasons.
If you'd like to have Create go back to xs:any+ then I'm open to a counter-proposal - but then I'd like to see some guidance on how RT fits into it - as you pointed out, they're not 'in-sync'. But, IMO, the xs:any* is a far better choice for the long term solution as it provides the most flexibility and extensibility.
thanks
-Doug
______________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
Geoff Bullen <Geoff.Bullen@microsoft.com>
Sent by: 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" <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
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
Geoff Bullen <Geoff.Bullen@microsoft.com>
02/02/2009 07:32 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,
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] On Behalf Of Doug Davis
Sent: Sunday, January 18, 2009 10:34 AM
To: 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
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.
thanks
-Doug
______________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6905 | dug@us.ibm.com
Received on Friday, 6 February 2009 15:46:02 UTC