Removed 5.4.8.1 and added 4.2.12 to better handle base/rel URI
authorsspeiche
Wed, 24 Jul 2013 07:31:14 -0400
changeset 224 39ca65760446
parent 223 b55c728b2f4d
child 225 3836f2670382
Removed 5.4.8.1 and added 4.2.12 to better handle base/rel URI
ldp.html
--- a/ldp.html	Wed Jul 24 07:16:13 2013 -0400
+++ b/ldp.html	Wed Jul 24 07:31:14 2013 -0400
@@ -441,6 +441,10 @@
 		to implement inferencing [[!RDF-CONCEPTS]].  The practical implication is that all content defined by LDP
 		must be explicitly represented. 
 	</div>
+	<div id="ldpr-4_2_12" class="rule">4.2.12 LDPR servers MUST assign the default base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP 
+		<code>Request-URI</code> when the resource already exists, and to the URI of the created resource when the request results 
+		in the creation of a new resource.
+	</div>
 
 </section>
 
@@ -1452,9 +1456,6 @@
 	<div id="ldpc-5_4_8" class="rule">5.4.8 LDPC servers SHOULD assign the subject URI for the resource to be
 		created using server application specific rules in the absence of a <a href="#ldpc-5_4_10">client hint</a>.
 	</div>
-	<div id="ldpc-5_4_8_1" class="rule">5.4.8.1 For RDF representations, LDPC servers MUST assign the base-URI for
-	   [[!RFC3987]] relative-URI resolution to be the URI of the created subject resource.
-	</div> 
 	<div id="ldpc-5_4_9" class="rule">5.4.9 LDPC servers SHOULD allow clients to create new resources without
 		requiring detailed knowledge of application-specific constraints.
 		This is a consequence of the requirement to 
@@ -1786,6 +1787,7 @@
 <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130701/">Third Public Working Draft</a></em></blockquote>
 -->
 <ul>
+	<li>2013-07-24 - Removed 5.4.8.1 and added 4.2.12 to better handle base/rel URI (SS)</li>
     <li>2013-07-23 - Added informative <a href="#ldpr-informative" class="sectionRef"></a>, therefore shifting all sections by one 4.1->4.2, etc (SS)</li>
 	<li>2013-07-23 - Changed <a href="#header-accept-post" class="sectionRef"></a> to at risk as possibly moving to IETF (SS)</li>
 	<li>2013-07-23 - ISSUE-53 4.2.3 changed MUST to SHOULD (SS)</li>