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: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
Date: Fri, 5 Apr 2013 10:35:51 +0200
Message-ID: <CAAOEr1k_XvwspOCfc73mcVp7iF9j8gzpJb-5wQwsuGYjPzD5WA@mail.gmail.com>
To: Linked Data Platform Working Group <public-ldp-wg@w3.org>
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 ?

Best Regards,
Received on Friday, 5 April 2013 08:36:39 UTC

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