Re: Conditional delete in LDP

PUT/PATCH/some-POSTs  would pretty obviously make sense, since that's 
where you get competing updates ... and that's where a lost update is 
*observable*.  It's not trivial to describe what subset of POSTs need to 
be in scope, but that might just be a good opportunity to wave our hands a 
bit and keep it at the "update" intent level.
DELETE is less obvious.  A competing update and delete can run in either 
order, and after both are done the results are the same so the difference 
is not observable.

Not having looked, would such a change even effect compliance?  I thought 
the conditional request language was at most a Should, so in theory... no 
effect if we chose to change it.  We might stage it through the 
non-normative companion documents now with a 1.0+1-level change, if we're 
worried about the optic of a late change.

Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead




From:   Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
To:     "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Cc:     John Arwe/Poughkeepsie/IBM@IBMUS, Steve Speicher 
<sspeiche@gmail.com>
Date:   06/25/2014 04:32 AM
Subject:        Conditional delete in LDP



Hi all,

There are two phrases in the LDP specification about the usage of e-tags. 
The former [1] requires the severs to send weak/strong etags and the 
latter [2] is about conditional requests.  

If the goal of using e-tags is to prevent the lost update problem, 
shouldn't we move the conditional request phrases from PUT to the general 
section and make it apply to all write requests (at least PUT and DELETE) 
? 

May be this is not the right time for changing anything but this is to 
clarify our intention. 

Best Regards,
Nandana

[1] http://www.w3.org/TR/ldp/#ldpr-gen-etags
[2] http://www.w3.org/TR/ldp/#h5_ldpr-put-precond