RE: Issue 6413: WS-Transfer with Extensible Fragment Support

Asir wrote:
Microsoft feels (quite frankly) that there seems to be a general lack of 
industry interest in generic partial updates, which leads us to be very 
wary of their value and place in the base Transfer specification that has 
been widely adopted and supported.

I think the _widely adopted_ WSMan specifications would disagree with the 
assessment that Fragment updates have a lack of industry interest.  Seems 
to me the real disagreement is on how best to specify this feature.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Asir Vedamuthu <asirveda@microsoft.com> 
03/31/2009 02:29 PM

To
Katy Warr <katy_warr@uk.ibm.com>, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org>
cc
David Snelling <David.Snelling@uk.fujitsu.com>, Doug 
Davis/Raleigh/IBM@IBMUS
Subject
RE: Issue 6413: WS-Transfer with Extensible Fragment Support






Our thoughts on issue 6413 ?
Partial CRUD?
 
Just like the sweet spot in REST/HTTP, based on usage patterns and 
adoption, it is fair to say that Transfer's sweet spot is in pushing and 
pulling data using Web Services. But, if you were to step slightly outside 
the sweet spot, say partial updates, then you are in a "deep tangly weeds" 
[1].
 
Once upon a time, HTTP used to have a method called PATCH for partial 
updates [2]. The PATCH method was dropped from HTTP because the method was 
not commonly implemented. Multiple Web Services specifications [3][4] 
introduced partial updates but we did not see much industry interest in 
these specifications.
 
Partial updates have a lot of tricky and unanswered issues [5][6] that the 
WG needs to think through.
 
Based on multiple partial CRUD proposals that we have seen thus far, it 
appears that a query component is represented as SOAP Body Blocks in a 
Transfer message. A REST/HTTP based approach suggest that a query is 
identified by a URI [7], not by message body content. The equivalent to a 
URI (including query) in HTTP, in Web Services, is an EPR. This suggests 
that the full identification of a resource should be in an EPR and not 
partly in a message body. In general, many of these generic partial CRUD 
proposals are at loggerheads with the REST/HTTP model. 
 
Microsoft feels (quite frankly) that there seems to be a general lack of 
industry interest in generic partial updates, which leads us to be very 
wary of their value and place in the base Transfer specification that has 
been widely adopted and supported.
Partial CRUD is Optional
 
During the WS-RA WG charter negotiation, there were good discussions 
[8][9] about partial CRUD features. But, there was no consensus. As a 
result, partial CRUD features were added to the charter as "optional" [10] 
? "the Working Group may address the following optimization-related 
topics: A mechanism by which a fragment of the XML representation of a 
resource can be identified for the purpose of accessing, updating or 
deleting it."
Raleigh WG F2F 2009
 
At the recent Raleigh WG F2F [11], the WG discussed why the WG should 
consider a merger proposal. Katy Warr, Doug Davis and Dave Snelling 
mentioned that there are some inconsistencies, overlaps and duplication 
between Transfer and Resource Transfer. We mentioned that these should be 
identified as separate issues. Thank you for following up and filing those 
technical issues!
 
Bob Freund mentioned that merging specs would introduce uncertainties and 
or interop problems caused by unnecessary optionality of partial CRUD 
operations in Transfer. 
 
Dave Snelling wanted to encourage a wider uptake of partial CRUD 
operations.
 
We walked through the consequences of merging:
 
a)  Introduces uncertainties caused by optional partial CRUD operations. 
This impacts communities that need a simple Transfer spec for pulling and 
pushing data. Currently, there are a number of dependant protocols that 
have taken functional dependencies on Transfer. These communities would be 
burdened to profile out partial CRUD operations
 
b)  Unnecessarily imposes Resource Transfer-level architectural concerns 
onto the Transfer spec
 
c)  Cannot meet the W3C Candidate Recommendation (CR) exit criteria. Thus 
far, it appears that only one participant is interested in implementing 
partial CRUD operations. This means, a merged specification will not meet 
the exit criteria.
 
We recall that Bob Freund identified a few important items that the WG 
need to consider when we discuss 6413:
 
a)  If there are any common stuff between Transfer and Resource Transfer 
that should be commonly defined
b)  Is RT an extension to Transfer? Are RT functions common operations? 
Are RT features optional?
c)  Some RT features raises too many questions, has problems and are 
unclear/broken.
 
There was WG consensus that the RT partial CRUD operations are SOAP 
Extensions that should compose with Transfer. We recollect that IBM/Katy 
was assigned an action [12] to prepare RT partial CRUD operations as SOAP 
Extensions to Transfer. We do not recollect any requests/mandate for yet 
another merger proposal.
Yet Another Partial CRUD Proposal
 
The current proposal [13] appears to 
 
a)  Drop the controversial boxcarring feature (this is progress)
b)  Invent a NEW attribute value based extensibility instead of the 
well-known SOAP Processing Model [14] (using SOAP Header Blocks) honored 
by commercial Web Services implementations
c)  Continue to suffer from well-known architectural concerns and
d)  Jam some parts of RT into appendices.
Least Objectionable Path Forward
 
Based on everyone preferences, it appears that the least objectionable 
path forward for the WG is:
 
1)  Fix any inconsistencies, overlap and duplication between Transfer and 
Resource Transfer
2)  Do not endanger the sweet spot. That is, continue to maintain simple 
(Transfer) and advanced features (Resource Transfer) as separate 
specifications
3)  Do it right. Continue to explore and or invent partial CRUD operations 
that compose well with Transfer using SOAP Header Blocks. Address 
architectural concerns. To encourage wider uptake (and show the value 
added by these features) of these advanced features, the WG should do it 
right!
 
We hope this helps.
 
[1] http://www.tbray.org/ongoing/When/200x/2008/02/16/HTTP-Sweet-Spot
[2] http://www.freesoft.org/CIE/RFC/2068/238.htm 
[3] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf
[4] http://schemas.xmlsoap.org/ws/2006/08/resourceTransfer/
[5] http://bitworking.org/news/296/How-To-Do-RESTful-Partial-Updates 
[6] http://blog.mozilla.com/rob-sayre/2008/02/15/restful-partial-updates/
[7] http://www.ietf.org/rfc/rfc3986.txt 
[8] http://lists.w3.org/Archives/Member/member-ws/2008Aug/0009.html 
[9] http://lists.w3.org/Archives/Member/member-ws/2008Aug/0019.html
[10] http://www.w3.org/2008/11/ws-ra-charter.html#scope
[11] http://www.w3.org/2002/ws/ra/9/03/2009-03-11.html#item05
[12] http://www.w3.org/2002/ws/ra/tracker/actions/39
[13] http://www.w3.org/2002/ws/ra/9/03/Issue-6413-2009-03-25.html
[14] http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#muprocessing
 
Regards,
 
Asir S Vedamuthu
Microsoft Corporation
 
From: public-ws-resource-access-request@w3.org 
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Katy Warr
Sent: Wednesday, March 25, 2009 9:23 AM
To: public-ws-resource-access@w3.org
Cc: David Snelling; Doug Davis
Subject: Issue 6413: WS-Transfer with Extensible Fragment Support
 

Following discussions on issue 6413 during the March F2F, Dave and I were 
tasked to create a new proposal that integrated basic fragment support 
(from WS-RT) into WS-T: http://www.w3.org/2002/ws/ra/tracker/actions/39. 

Dave, Doug and I have worked on this and have the following proposal: 

A key requirement of this action item was minimum change to the core WS-T 
specification (as the amount of change to the WS-T spec was a concern with 
the initial proposal).  With this in mind, our proposal adds only an 
optional 'Dialect' attribute to each operation.  This attribute specifies 
how the extensibility elements in the in the body will be processed - thus 
providing a fully extensible mechanism to the WS-Transfer spec, but with 
minimum changes. 

We were sensitive to the fact that WS-T implementations should not need to 
process the soap body unnecessarily.  The dialect attribute has the useful 
side effect of indicating whether processing of extensibility elements in 
the soap body is required.   More importantly, its absence indicates when 
processing is not required.  For the Get and Delete operations, (where 
processing of the body is not necessary if there is no extensibility), we 
state: "When this attribute is not present, child elements of the wst:Get 
MUST be ignored." 

In terms of dialect definition, we have defined one dialect only: XPath 
Level 1 Expression Dialect and this is contained in Appendix A. 
Implementation of this dialect is optional and other (optional) dialects 
may be defined by other specifications.  The XPath Level 1 Expression 
Dialect was chosen because it satisfies the core fragment use cases 
without introducing additional complexity.   XPath Level 1 restricts the 
evaluation of an XPath 1.0 expression to a single element thus providing 
simple fragment support for the majority of use cases.  Multiple elements 
could still be targeted via an XPath Level 1 expression by inclusion of a 
parent element by the application to encapsulate child multiple elements. 

Note the following with respect to the defined  XPath Level 1 expression 
dialect: 
- We have restricted the dialect to disallow multiple fragment support 
(i.e. only one expression/fragment per request).   Again, this was to 
ensure that we were covering core use case without introducing unnecessary 
complexity. 
- For simplification, we have not introduced the Put 'Mode' element from 
WS-RT.  Fragment deletion may be performed with Delete and the XPath Level 
1 expression dialect.  Fragment insertion may be performed with Create and 
the XPath L 1 Dialect. 

Note that the schema has not been updated to reflect the proposal as it 
seemed prudent to await decision by the group prior to spending time on 
this. 

The proposed document with markup in word and html is here: 
http://www.soaphub.org/public/files/w3c/WSTWithBasicFragmenSupport.htm 
http://www.soaphub.org/public/files/w3c/WSTWithBasicFragmenSupport.doc 

Thanks, 
Katy 



 
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