ldp.html
changeset 104 78fd14175304
parent 102 04e3e77e4e78
child 105 6f2f1329086d
--- a/ldp.html	Tue Apr 30 16:46:56 2013 +0200
+++ b/ldp.html	Wed May 08 09:55:53 2013 -0400
@@ -575,17 +575,15 @@
 	</p>
 	<p>This document includes a set of guidelines for
 		using POST to create new resources and add them to the list of
-		members of a container. This document also explains how to include
+		members of a container. It goes on to explain how to learn about a set of related
+		resources, they may have been created using POST or through other means.
+		This document also explains how to include
 		information about each member in the container’s own representation
-		and how to paginate the container representation if it gets too big.</p>
-	<p>The model for containers follow that of two distinct types: composition and aggregation.  Due to composition
-	   constraints, the lifespan of the member resource must match that of its container and it a member resource 
-	   can not be a member of more than one container. For both types of containers, members are 
-	   only added by using POST, which both creates the resource and inserts a membership triple.
-	   A request to delete a composite container that has members, will result in all 
-	   the members and the container itself will be deleted. A member resource is removed
-	   from a composite container by deleting the resource directly, which removes the
-	   membership triple from the container.</p>
+		and how to paginate the container representation if it gets too big.
+		It also defines behavior when POST created resources are deleted, to clean up
+		container membership, and deleting containers removes membership information and
+		possibly perform some cleanup tasks on unreferenced member resoruces.</p>
+
 	<p>The following illustrates a very simple
 		container with only three members and some information about the
 		container (the fact that it is a container and a brief title):</p>
@@ -975,10 +973,9 @@
 	<div id="ldpc-5_2_1" class="rule">5.2.1 LDPC servers MUST also be conformant LDPR servers. A Linked Data Platform
 		Container MUST also be a conformant Linked Data Platform Resource.
 	</div>
-	<div id="ldpc-5_2_2" class="rule">5.2.2 For LDPC's of <code>rdf:type</code> of <code>ldp:CompositeContainer</code>,
-	the same resource which is identified by its canonical URI, MUST be a member of 
-	only a single <code>ldp:CompositeContainer</code>. The same resource can not be a member of multiple Composite LDPCs. The
-	same resource can be a member of multiple LDPCs of <code>ldp:AggregateContainer</code>.
+	<div id="ldpc-5_2_2" class="rule">5.2.2 For LDPC's of <code>rdf:type</code> of <code>ldp:Container</code>,
+	the same resource which is identified by its canonical URI, MAY be a member of 
+	more than one <code>ldp:Container</code>.
 	</div>
 	<div id="ldpc-5_2_3" class="rule">5.2.3 The state of an LDPC includes information about which
 		resources are its members. In the simplest cases, the membership subject
@@ -1248,24 +1245,16 @@
 		only when a LDPC supports that method.  This specification does not impose any
 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
 		
-	<div id="ldpc-5_6_1" class="rule">5.6.1 When a LDPC member resource originally created by the LDPC (for example, one referenced by
-		a membership triple) is deleted, and the LDPC server is aware of the member's deletion
+	<div id="ldpc-5_6_1" class="rule">5.6.1 When a LDPC member resource originally created by the LDPC (for example, one whose representation
+	    was HTTP POST'd to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion
 		(for example, the member is managed by the same server), the LDPC server MUST also remove it from
 		the LDPC by removing the corresponding membership triple.
 	</div>	
-	<div id="ldpc-5_6_2" class="rule">5.6.2 When the LDPC includes an <code>rdf:type</code> predicate with an object of <code>ldp:AggregateContainer</code>,
-		the server MAY also delete the resources that are referenced as its contents.  
-		The LDPC membership triple MUST also be updated as defined by <a href="#ldpc-5_6_1">5.6.1</a> above.
+	<div id="ldpc-5_6_2" class="rule">5.6.2 When the LDPC server successfully completes the DELETE request on a LDPC, it MUST remove any
+		membership triples associated with the LDPC as indicated by the canonical Request-URI.  The LDPC server MAY perform additional removal 
+		of member resources. The server could decide some additional cleanup tasks for resources it knows are no longer referenced or have not
+		been accessed for some period of time.
 	</div>
-	<div id="ldpc-5_6_3" class="rule">5.6.3 When the LDPC includes an <code>rdf:type</code> predicate with an object of <code>ldp:CompositeContainer</code>,
-		the server MUST also delete the resources that are referenced as its contents.  
-		The LDPC membership triple MUST also be updated as defined by <a href="#ldpc-5_6_1">5.6.1</a> above.
-	</div>
-	
-	<div class="ldp-issue">
-	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/59">ISSUE-59</a></div>
-	Recursive delete: reconsider usage of Aggregate/Composite construct to get predictable container delete behavior
-	</div>	
 	
 	<div class="ldp-issue">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/28">ISSUE-28</a></div>
@@ -1321,6 +1310,7 @@
 </p>
 <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130307/">Second Public Working Draft</a></em></blockquote>
 <ul>
+	<li>2013-05-08 - ISSUE-59 5.3.2 limited rdf:type of ldp:Container, removed 5.6.3, reworded 5.6.2, updated 1. (SS)</li>
 	<li>2013-04-15 - ISSUE-21 Added ldp:membershipPredicateInverse to 5.2.5 &amp; 5.5.2, created 5.2.5.1 &amp; 5.3.5.2 to indicate difference. (SS)</li>
 	<li>2013-04-15 - ISSUE-39 Moved informative text from 5.4.5 into 5.4.1, shifted subsections .6-.10 (SS)</li>
 	<li>2013-04-15 - Expanded on wording for 4.3 to be more consistent (SS)</li>