W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2014

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

From: Alexandre Bertails <alexandre@bertails.org>
Date: Wed, 26 Nov 2014 13:50:02 -0500
Message-ID: <CANvn8kxD=O2=ndYM83nXp3z1BjdfQSadkZdrwoySYREHZu8Esw@mail.gmail.com>
To: Tim Berners-Lee <timbl@w3.org>
Cc: Steve Speicher <sspeiche@gmail.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, Arnaud Hors <lehors@us.ibm.com>, Sandro Hawke <sandro@w3.org>
Hi Tim,

On Wed, Nov 26, 2014 at 1:30 PM, Tim Berners-Lee <timbl@w3.org> wrote:
>
> On 2014-11 -24, at 23:07, Alexandre Bertails <alexandre@bertails.org> wrote:
>
>> 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?
>
> No, I think that we need to leave app designers the option of not using eTag.
>
> eTag means you have to sync up, and if something is changing frequently then you are likely  to be  caught constantly reloaded a resource and never being able to edit it.    Imagine a single resource which contains say the lines of a etherpad session, where people are interactively editing different, or somethings the same line, in  a random way.  You might want to design the app so it does optimistic concurrency,  sending in changes in a torrent and backing back out at the UI the ones which get a conflict error.    Maybe not a great example, but insisting that people use eTag rules out this more optimistic concurrency.

I understand this use-case as well. Forcing the use of ETags is not
always practical.

>
>
>>
>>> 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.
>
> I think in fact two ldpatch verbs, delete and deleteAny would be simple way to solve this problem.

I was expecting this answer :-)

But I don't want to constrain us with this specific solution for now,
that is: two Delete-s. There are other related questions to discuss to
make the choice consistent with the other operations. I will come up
with a list of proposals for the next meeting so that the group can
see what options are available, with their trade-offs.

>> If ETags are not an option for you, would you like to make a suggestion?
>
>
> I am happy for etags to to be available for others.
> I may indeed use it for some apps.
>
> Another comment on the spec:  you need to specify how the new etag value back from the server.

You mean generally? Or in the response to a PATCH request? I am
wondering what the spec should say beside what the HTTP PATCH and
ETags spec say. I was thinking that a non-normative remark would have
been enough.

Alexandre



>
> Tim
>
>>
>> Cheers,
>>
>> Alexandre
>>
>> [1] http://tools.ietf.org/html/rfc5789
>>
>>
>>>
>>>
>>> timbl
>>>
>>>
>>
>
Received on Wednesday, 26 November 2014 18:50:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:59 UTC