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

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.

On Tue, Mar 19, 2013 at 8:10 AM, Linked Data Platform (LDP) Working
Group Issue Tracker <sysbot+tracker@w3.org> wrote:
> ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core]
>
> http://www.w3.org/2012/ldp/track/issues/59
>
> Raised by: Steve Speicher
> On product: Linked Data Platform core
>
> The origins of the need for concepts of Aggregate and Composite type containers was from the desire to be able to have predictable delete behavior, instead of leaving it unspecified and therefore implementation dependent (see ISSUE-34).   As the editors have made the changes for these concepts, feedback from the editors and WG members is that they terminology and concepts add confusion for the simple needs for clear delete semantics.   Instead, having a simple resource and container model is preferred.  Then having a delete model that meets the recursive needs is desired.
>
> 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.  Introduce a "recursive delete" mechanism, that deletes the container and issues a DELETE on all its members (if the members are also containers, it recurses the delete).  The server may not be able to successfully delete the members but will at least attempt the DELETE.  It would seem unreasonable for the errors on deletion of members to be composed into a error report in that it would be infrequently used and come at a cost to produce.  Clients that need to know, could know based on some condition or minimal error response, then attempting to access member resources.
>
> There are a number of ways that (b) can be solved that don't require a new rdfs:Class to be introduced.  For example, since introducing a new HTTP verb is probably too heavyweight, it might be ideal to expose a "recursive delete" URL that a client can find (either in RDF or header) that a DELETE on this URL will invoke the recursive behavior.
>
>
>



--
- Steve

Received on Thursday, 4 April 2013 20:02:22 UTC