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

Thanks Steve for bringing this up. Even though I'd like us to be done with 
this issue of containers it's clear to me that the status quo isn't really 
satisfying anybody and a different approach is worth considering.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group




From:   "Linked Data Platform (LDP) Working Group Issue Tracker" 
<sysbot+tracker@w3.org>
To:     public-ldp-wg@w3.org, 
Date:   03/19/2013 05:11 AM
Subject:        ldp-ISSUE-59 (recursive-delete): Reconsider usage of 
Aggregate/Composite construct to get predictable container delete behavior 
[Linked Data Platform core]



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.