Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior - take #2

Hi all, 

Last week I tried to get us to a resolution on this issue but we didn't 
quite get to it. I'd like to try again. We actually have 3 different ways 
to do so:

** Option A: Close Issue-59 per Steve's suggestion (see 
http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0018.html ): 

1. remove the two types of container AggregateContainer and 
CompositeContainter, leaving the only kind of container to be 
ldp:Container 

2. specify that on deleting a container LDP servers MUST delete the 
container and MAY delete member resources (typically to satisfy internal 
requirements). 

So if I have: 

<> a ldp:Container; 
   rdfs:member <a>. 

and I create <b> using POST to the container, I end up with: 

<> a ldp:Container; 
   rdfs:member <a>, <b>. 

When I delete the container, the container gets deleted, and <a> and <b> 
MAY get deleted. 

3. Defer adding an operation that let's a client request a recursive 
delete to a future version of LDP.
------------- 

** Option B: The following alternative, inspired by Henry's proposal 
around ldp:contains: 

1. remove the two types of container AggregateContainer and 
CompositeContainter, leaving the only kind of container to be 
ldp:Container 

2. add that on creating a new member resource using POST, LDP servers 
SHOULD add a triple a la : <> ldp:contains <newly_created_resource> if the 
resource will be deleted when the container is deleted. Note that this is 
in addition to adding the appropriate ldp:membershipPredicate or 
ldp:membershipPredicateInverse triple to the container representation as 
currently required. 

3. specify that on deleting a container LDP servers MUST delete the 
container and member resources listed as contained via ldp:contains, and 
MAY delete other member resources (typically to satisfy internal 
requirements). 

So if I have: 

<> a ldp:Container; 
   rdfs:member <a>. 

and I create <b> using POST to the container, I end up with: 

<> a ldp:Container; 
   rdfs:member <a>, <b>; 
   ldp:contains <b>. 

When I delete the container, both the container and <b> get deleted. <a> 
MAY be deleted. 

4. Defer adding an operation that let's a client request a recursive 
delete to a future version of LDP.
------------- 

** Option C: Leave the spec as it currently stands, keeping the two types 
of container: AggregateContainer and CompositeContainter


Note that as it was pointed out last week, both options B & C mean doing 
more work because each of this option raise their own set of additional 
issues we will need to resolve. Off the top of my head, this includes what 
it means to "move" a contained resource from one container to another in 
option B, and whether a container can be changed from one type to the 
other in option C.

Thanks.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group