- From: Alexandre Bertails <alexandre@bertails.org>
- Date: Wed, 26 Nov 2014 13:50:02 -0500
- 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