ISSUE-25 made changes for composition model
authorsspeiche
Wed, 16 Jan 2013 15:38:37 -0500
changeset 42 2aeef316040a
parent 41 634a37de3539
child 43 6d2805d7c6bf
ISSUE-25 made changes for composition model
ldp.html
--- a/ldp.html	Sat Jan 12 14:15:50 2013 -0500
+++ b/ldp.html	Wed Jan 16 15:38:37 2013 -0500
@@ -215,7 +215,7 @@
 	@prefix dcterms: <http://purl.org/dc/terms/>.
 	@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
 	@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#>.
-	@prefix ldp:      <http://www.w3.org/ns/ldp#>.
+	@prefix ldp:     <http://www.w3.org/ns/ldp#>.
 	@prefix xsd:     &lt;http://www.w3.org/2001/XMLSchema#&gt;.</pre>
 </section>
 </section>
@@ -677,6 +677,14 @@
 		members of a container. 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 strong composition.  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. Members are 
+	   only added by using POST, which both creates the resource and inserts a membership triple.
+	   A request to delete a container that has members, will result in all 
+	   the members and the container itself will be deleted. A member resource is removed
+	   from a container by deleting the resource directly, which removes the
+	   membership triple from the container.</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>
@@ -726,17 +734,17 @@
 
 	<p>
 		The essential structure of the container is
-			the same, but in this example, the membership subject is not the
-			container itself – it is a separate net worth resource. The
-			membership predicate is <code>o:asset</code> – a predicate from the domain model. A POST to
-			this container will create a new asset and add it to the list of
-			members by adding a new membership triple to the container. You
-			might wonder why we didn’t just make <code>http://example.org/netWorth/nw1</code> a container and POST
-			the new asset directly there. That would be a fine design if <code>http://example.org/netWorth/nw1</code> had only assets, but if it has separate
-			predicates for assets and liabilities, that design will not work
-			because it is unspecified to which predicate the POST should add a
-			membership triple. Having separate <code>http://example.org/netWorth/nw1/assetContainer</code> and <code>http://example.org/netWorth/nw1/liabilityContainer</code> container resources allows both assets and
-			liabilities to be created.
+		the same, but in this example, the membership subject is not the
+		container itself – it is a separate net worth resource. The
+		membership predicate is <code>o:asset</code> – a predicate from the domain model. A POST to
+		this container will create a new asset and add it to the list of
+		members by adding a new membership triple to the container. You
+		might wonder why we didn’t just make <code>http://example.org/netWorth/nw1</code> a container and POST
+		the new asset directly there. That would be a fine design if <code>http://example.org/netWorth/nw1</code> had only assets, but if it has separate
+		predicates for assets and liabilities, that design will not work
+		because it is unspecified to which predicate the POST should add a
+		membership triple. Having separate <code>http://example.org/netWorth/nw1/assetContainer</code> and <code>http://example.org/netWorth/nw1/liabilityContainer</code> container resources allows both assets and
+		liabilities to be created.
 	</p>
 	<p>In this example, clients cannot simply guess
 			which resource is the membership subject and which predicate is the
@@ -1022,9 +1030,8 @@
 	<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 The same resource MAY be a member of multiple LDPCs. This happens
-		commonly if one container is a view onto a larger container.
-	</div>
+	<div id="ldpc-5_2_2" class="rule">5.2.2 The same resource, identified by its canonical URI, MUST be a member of 
+	only a single LDPC. The same resource can not be a member of mutliple LDPCs.</div>
 	<div id="ldpc-5_2_3" class="rule">5.2.3 The state of a LDPC includes information about which
 		resources are its members. In the simplest cases, the membership subject
 		will be the LDPC resource itself, but it does not have to be. The
@@ -1241,15 +1248,14 @@
 		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 If a LDPC server supports deletion of the LDPC, the server MAY also
-		delete the resources that are referenced as its contents.
+	<div id="ldpc-5_6_1" class="rule">5.6.1 When a resource that is contained in a LDPC (for example referenced by
+		a membership triple) is deleted, the server MUST also remove it from
+		the LDPC by removing the membership triple.
+	</div>	<div id="ldpc-5_6_2" class="rule">5.6.2 If a LDPC server supports deletion of the LDPC, the server MUST also
+		delete the resources that are referenced as its contents.  The LDPC memebership triple MUST also be updated as defined
+		by <a href="#ldpc-5_6_1">5.6.1</a> above.
 	</div>
-	<div id="ldpc-5_6_2" class="rule">5.6.2 When a resource that is contained in a LDPC (for example referenced by
-		a membership triple) is deleted, the server MUST also remove it from
-		the LDPC that was used to create it and SHOULD remove it from any
-		other containers that reference it that the server manages and
-		persists.
-	</div>
+
 </section>
 
 <section>
@@ -1311,6 +1317,7 @@
 	Text being repeated in several places centralized and cross-linked.  Made printed code output easier to read
 	on black & white printers.  Exposed terms defined in-line under LDPC as Terminology (tentatively).  Removed non-normative
 	qualifer from section 5.2.  Added "several" editors' to-dos.(JA)</li>
+	<li>2013-01-16 - ISSUE-25 Updated introduction. 5.2.2 changed to MUST NOT be in multiple containers. Flipped 5.6.1/2 as first rule leads to 2nd. 5.6.2(was .1) Delete LDPC MUST also delete members.</li>
 </ul></section>
 
 <section class='appendix informative' id="todos">