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

Hi Steve:
Sorry I missed your original mail on this.
I have two problems with b)
1. I thought that one of our central concepts was association in which you do a
PUT on the container both to create a resource and file it in the container.  Such
resources are deleted when then the container is deleted.
Are we going back on this functionality?
2. If you allow deleting a container while it still has members in it, it may lead to
members becoming unreachable.  This is a bad thing.

So, I would vote for two types of containers (or two flavors) one in which the members
are deleted when the container is deleted and the other in which members are not deleted
and the user is warned that some members may become unreachable. Not crazy about this.
Alternately, we prohibit the deletion of a container if it contains members.  This may be simpler.
All the best, Ashok
On 4/5/2013 4:35 AM, Nandana Mihindukulasooriya wrote:
> Hi Steve,
>
> On Thu, Apr 4, 2013 at 10:01 PM, Steve Speicher <sspeiche@gmail.com <mailto: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,
> Nandana