RE: [Bug 8193] Fragment: Replace mode could be clearer

For a client that was doing a full update previously, it makes sense to treat the Fragment Put as an optimization. Such a client would not be acting any differently between a Fragment Put Insert and Fragment Put Replace.

On the other hand, WS-Fragment allows for the possibility of clients that operate exclusively at the fragment level. In this case, the client has no interest in verifying the effect of the fragment updates on the full representation nor is it capable of doing so since the resource may be too large to retrieve. Further, the client treats the fragment updates independently and not relative to the full representation. In these cases, the client may choose to take different internal actions based on the nature of the fragment updates.

An example is:


1.        Transfer Create (creation_instructions)

a.       Create a resource based on creation_instructions.

2.       Update the resource using Fragment updates

a.       Do Fragment Put Insert (f) then take Action A

b.      Do Fragment Put Replace (f with g) then take Action B

c.       Do Fragment Put Delete (g) then take Action C

In the above example, Action B assumes that there is an fragment (f) exists. If (f) does not exist, then it is important for the client to know that (f) does not exist. Hence, it would break the client logic if Replace (f with g) inserted (g) even when (f) does not exist.

Thanks.

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Monday, January 25, 2010 4:15 PM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org
Subject: RE: [Bug 8193] Fragment: Replace mode could be clearer


I'm not following.  Can you show me an example set of message exchanges for the case you have in mind?

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

Ram Jeyaraman <Ram.Jeyaraman@microsoft.com<mailto:Ram.Jeyaraman@microsoft.com>>

01/25/2010 12:56 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: [Bug 8193] Fragment: Replace mode could be clearer







There are cases where the fragment updates are not an optimization. For example, the resource may be sufficient large and the only way to manipulate the resource is via fragment updates. In such cases, it is important to keep the semantics of Replace and Insert intact. Thanks.

From: Doug Davis [mailto:dug@us.ibm.com]<mailto:[mailto:dug@us.ibm.com]>
Sent: Sunday, January 24, 2010 7:03 PM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>
Subject: RE: [Bug 8193] Fragment: Replace mode could be clearer


Ram,
 Take a step back and forget about fragments for a moment.  If the client in your situation only had full Put at its disposable then it would be left with the choice of doing something based on whether the final resource representation matched what it wanted and nothing more.  The exact soap messages aren't really of interest to the client - what matters is getting the resource to look like what it wants.  Fragment Put should be the same.  If a client really wants to do different things based on whether there is something already present in the resource then it needs to be the same for full Put and fragment Put - remember Fragment Put is just an optimization. And in the case of full Put, the way the client does this is by examining the resource's representation either before or after the Put. Trying to embed this conditionality into the service's fragment Put logic breaks the model of fragment Put just being an optimization.
 To make my point, look at an example of full Put:
original resource A:
 <foo/>
original resource B:
 <foo>
   <bar/>
 </foo>
Put request contains:
 <foo>
   <xyz/>
 </foo>

Whether we're updating resource A or resource B, does it really matter whether people conceptually think of it as a Replace or Insert?  It doesn't in the full Put case, so why do we care in the fragment Put case?  I content that it doesn't - what matters is that the end result is what the client wants.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.
Ram Jeyaraman <Ram.Jeyaraman@microsoft.com<mailto:Ram.Jeyaraman@microsoft.com>>
Sent by: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>

01/23/2010 06:30 PM


To

"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>>

cc

Subject

RE: [Bug 8193] Fragment: Replace mode could be clearer











Allowing a Replace to act like an Insert can cause problems. For example, a client logic may be such that it may do action A upon successful completion of an insert and action B upon successful completion of a Replace. If the resource allowed a Replace to pass through as if it was an Insert, then the client logic (action B) will do the wrong thing since it assumes the existence of a node in the representation that was replaced. To avoid this situation and to ensure that the client view and the service view of the resource are in sync, it is important to keep the semantics of Replace and Insert distinct.

-----Original Message-----
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Ram Jeyaraman
Sent: Saturday, January 02, 2010 11:03 AM
To: public-ws-resource-access@w3.org
Subject: RE: [Bug 8193] Fragment: Replace mode could be clearer

For the Put operation: The Insert mode should add new items, Delete mode should remote items, and Replace should modify existing items.

Along the same lines, if a Replace is operated on a non-existent item, then a fault should be raised.

-----Original Message-----
From: public-ws-resource-access-notifications-request@w3.org [mailto:public-ws-resource-access-notifications-request@w3.org] On Behalf Of bugzilla@wiggum.w3.org
Sent: Wednesday, November 04, 2009 3:34 PM
To: public-ws-resource-access-notifications@w3.org
Subject: [Bug 8193] Fragment: Replace mode could be clearer

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8193





--- Comment #1 from Doug Davis <dug@us.ibm.com<mailto:dug@us.ibm.com>>  2009-11-04 23:34:08 --- Frag says:
--
[Body]/wst:Put/wsf:Fragment/wsf:Expression@Mode="http://www.w3.org/2009/09/ws-fra/Modes/Replace"

  When the Mode attribute is set to a value of "http://www.w3.org/2009/09/ws-fra/Modes/Replace" the resource representation specified within the Value element MUST replace the entire resource representation referenced by the children of the Expression element, if it exists.
--

While its implied that if the Expression points to something that doesn't exist it should just add it, we need to make it clear.

Proposal:
Add to the end of the above text add:
--
If it doesn't exist then the Value is simply added to the resource representation.
--


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: ------- You are the QA contact for the bug.
You are the assignee for the bug.