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

To help the Working Group process issue 6413, we posted a set of issues from our initial review of the proposal:

6413-A: Really a mandatory extension, not an optional one
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0069.html 

6413-B: Changes semantics of its parent
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0070.html 

6413-C: Overrides WS-Transfer extension processing model
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0071.html 

6413-D: Dropped Boxcarring
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0072.html 

6413-E: Drops substantial RT features
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0073.html 

6413-F: XPath Subset
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0074.html 

6413-G: Core Fragment Use Cases?
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0075.html 

6413-H: Status of Appendices?
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0077.html 

6413-I: Review of XPath Dialect
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0078.html 

6413-J: May Not Meet Candidate Recommendation Exit Criteria
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0079.html 

As always, we are open to work with issue owners to process the issue. We hope that other members of the Working Group and WS-RA WG mailing list subscribers are reviewing the proposal as well.

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 

Received on Saturday, 11 April 2009 00:14:17 UTC