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

Between the options of "Replace with implicit Insert" and "Replace and 
fail on absent target" it looks like "6 of one, a half dozen of 
another". In the "Replace and fail on absent target", all you have do to 
make up for that lack of an implicit Insert is an additional Get and 
then choose between doing a Replace or an Insert. In "Replace with 
implicit Insert", if it turns out that you *don't* want to do the insert 
(i.e. you want to fail on the lack of a target to replace), you just 
have to do the same additional Get before the operation and go to your 
failure case if the target fragment doesn't exist.

This might be a real argument if we were talking about the transactional 
boundaries around these two options, which hopefully, we are not.

- gp

On 1/26/2010 11:16 AM, Ram Jeyaraman wrote:
>
> 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.
>
>
>
>