W3C home > Mailing lists > Public > public-ldp-wg@w3.org > April 2013

Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core]

From: Steve Speicher <sspeiche@gmail.com>
Date: Fri, 5 Apr 2013 09:09:12 -0400
Message-ID: <CAOUJ7Jq+0V5-vk6YAMnCLBK6ZDkPY7VpX1vy1ZUmMhE-tChy2Q@mail.gmail.com>
To: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
Cc: Linked Data Platform Working Group <public-ldp-wg@w3.org>
On Fri, Apr 5, 2013 at 4:35 AM, Nandana Mihindukulasooriya
<nmihindu@fi.upm.es> wrote:
> Hi Steve,
> On Thu, Apr 4, 2013 at 10:01 PM, Steve Speicher <sspeiche@gmail.com> wrote:
>> I believe we have started to settle on this a bit and would like to
>> reword the proposal based on the feedback thus far:
>> Proposal:
>> a) Remove the concepts of AggregateContainer and CompositeContainer.
>> Leaving the only kind of container to be ldp:Container
>> b) Have DELETE on a container only delete the container itself, not
>> its members.  This would include removing the membership triples.  The
>> resources identified by the object of the membership triples, may or
>> may not be deleted by the server.  Note: this is just like deletion of
>> any other resource (container or not) where the server may decide to
>> cleanup up not-linked-to resources.  There is always a chance that a
>> link to the resource may exist beyond what the LDP server knows and it
>> is probably the best judge of when to do some housecleaning (using
>> other heuristics such as when or how often it was last accessed).
>> Out of scope (put on the "potential futures" list):
>> c) Recursive-delete : since it seems like a key feature WG members are
>> looking for is some kind of affordance of what will get deleted (or
>> what has been deleted).  This starts to head down a way to describe
>> what permissions are allows (access-control), which is outside of the
>> scope of the 1.0 spec.
> So in other words, what b) is saying that servers may do recursive-delete
> (i.e. it is not prohibited) but there is no guarantee in the protocol it
> does or does not. So as a client if I want to make sure the whole membership
> tree is deleted, I have to traverse the tree deleting each resource one by
> one though (as in any other case) the server or someone else might have
> already deleted them. And as a client if this guarantee is not necessary for
> me, I might just delete the container. Then it becomes the responsibility of
> the server to do the cleanup based on the knowledge it has about the data,
> business logic, or any other heuristics. If these undiscoverable resources
> are indeed garbage, and if the server does not do any housecleaning then it
> is an issue of the server. In contrast, if they are not, some servers might
> even have policies that they will not permit containers do be deleted until
> all it is members are deleted i.e. I would get an error when I try to delete
> a non-empty container. I think the protocol does not guarantee nor prohibit
> this. Am I correct ?

Hi Nandana,


- Steve Speicher

> Best Regards,
> Nandana
Received on Friday, 5 April 2013 13:09:38 UTC

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