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