Re: Need for hard fail on missing delete triples Re: Updated LD Patch specification

Tim,

On Mon, Nov 24, 2014 at 10:50 PM, Tim Berners-Lee <timbl@w3.org> wrote:
>
> On 2014-11 -24, at 16:07, Alexandre Bertails <alexandre@bertails.org> wrote:
>
>> On Mon, Nov 24, 2014 at 4:00 PM, Steve Speicher <sspeiche@gmail.com> wrote:
>>> On Mon, Nov 24, 2014 at 3:52 PM, Alexandre Bertails
>>> <alexandre@bertails.org> wrote:
>>>> On Mon, Nov 24, 2014 at 3:42 PM, Steve Speicher <sspeiche@gmail.com> wrote:
>>>>> On Mon, Nov 24, 2014 at 2:30 PM, Alexandre Bertails
>>>>> <alexandre@bertails.org> wrote:
>>>>>> On Mon, Nov 24, 2014 at 2:10 PM, Steve Speicher <sspeiche@gmail.com> wrote:
>>>>> ...snip...
>>>>>>>
>>>>>>> <#delete-statement> I wonder about this requirement:
>>>>>>> "It fails if one of those triples does not exist in the target graph." and later
>>>>>>> "If a Delete attempts to remove a non-existing triple, then a HTTP 422
>>>>>>> (Unprocessable Entity) error status code must be returned."
>>>>>>> I wonder why this requirement exists?
>
>
> For example,
>
> 1)  if two users are updating the same application data,
> if they make conflicting changes you may want one of them to fail with a beep and the other to succeed.
>
> 2) As another example, if you want to give out a series of identifiers one way is to increment
> a triple
>
>         :foo :nextSequence 9.
> to say
>         :foo :nextSequence 10.
>
> so that you have uniquely claimed sequence number 9.
> If someones else tries first, you get a failure.
>
> My current software returns 409 Conflict
> This also suggested in the 2009 note
> http://www.w3.org/DesignIssues/ReadWriteLinkedData.html

We discussed the option of using ETags for handling this use-case.
This is another way to detect conflict, also resulting with a 409
Conflict.

Would you be happy with that option?

> Not sure why the spec suggests 422 instead.
> Maybe a good reason.

Delete-ing a non-existing triple can happen because of conflict, but
more generally it is just an "unprocessable request". Here is the
corresponding text from the relevant RFC  [1]:

[[
   Unprocessable request:  Can be specified with a 422 (Unprocessable
      Entity) response ([RFC4918], Section 11.2) when the server
      understands the patch document and the syntax of the patch
      document appears to be valid, but the server is incapable of
      processing the request.
]]

> I can see others having a different requirement for a "delete if it exists" which does fail silently if it doesn't.

If ETags are not an option for you, would you like to make a suggestion?

Cheers,

Alexandre

[1] http://tools.ietf.org/html/rfc5789


>
>
> timbl
>
>

Received on Tuesday, 25 November 2014 04:08:08 UTC