ISSUE-49 Moved section 4.1.4 out of spec to the deployment guide
authorsspeiche
Mon, 13 May 2013 09:27:54 -0400
changeset 107 e35e3ea7be90
parent 106 3e59d43671df
child 108 075acf700bb9
ISSUE-49 Moved section 4.1.4 out of spec to the deployment guide
ldp.html
--- a/ldp.html	Fri May 10 14:39:52 2013 +0200
+++ b/ldp.html	Mon May 13 09:27:54 2013 -0400
@@ -299,40 +299,26 @@
 		is common for LDPR servers to need to host binary or text resources
 		that do not have useful RDF representations.
 	</div>
-	<div id="ldpr-4_1_4" class="rule">4.1.4 Clients can access an LDPR using multiple
-			URLs, for example when DNS aliasing is used. An LDPR server MUST
-			respond to each of those requests using a single consistent URL, a
-			canonical URL, for the LDPR which may be found in the response's
-			Location header and potentially also in the representation of the
-			LDPR. Clients SHOULD use the canonical URL as an LDPR's identity;
-			for example, when determining if two URLs refer to the same resource clients
-			need to compare the canonical URLs not the URLs used to access the resources.
 
-	<div class="ldp-issue">
-	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/49">ISSUE-49</a></div>
-	Canonical URL - how to communicate its value to clients
-	</div>
-	</div>
-	
-	<div id="ldpr-4_1_5" class="rule">4.1.5 LDPRs SHOULD reuse existing vocabularies instead of creating
+	<div id="ldpr-4_1_4" class="rule">4.1.4 LDPRs SHOULD reuse existing vocabularies instead of creating
 		their own duplicate vocabulary terms.  In addition to this general rule, some specific cases are
 		covered by other conformance rules.
 	</div>
-	<div id="ldpr-4_1_5_1" class="rule">4.1.5.1 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
+	<div id="ldpr-4_1_4_1" class="rule">4.1.4.1 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
 		[[!DC-TERMS]], RDF [[!RDF-PRIMER]] and RDF Schema [[!RDF-SCHEMA]], whenever
 		possible.
 	</div>
-	<div id="ldpr-4_1_6" class="rule">4.1.6 LDPRs MUST use the predicate <code>rdf:type</code> to
+	<div id="ldpr-4_1_5" class="rule">4.1.5 LDPRs MUST use the predicate <code>rdf:type</code> to
 		represent the concept of type. The use of non-standard type
 		predicates, as well as <code>dcterms:type</code>, is
 		discouraged, as it is not recommended
 		by the Dublin Core Metadata Initiative for use with RDF resources [[!DC-RDF]]. 
 	</div>
-	<div id="ldpr-4_1_7" class="rule">4.1.7 LDPR representations SHOULD have at least one <code>rdf:type</code>
+	<div id="ldpr-4_1_6" class="rule">4.1.6 LDPR representations SHOULD have at least one <code>rdf:type</code>
 		set explicitly.  This makes the representations much more useful to
 		client applications that don’t support inferencing.
 	</div>
-	<div id="ldpr-4_1_8" class="rule">4.1.8 Predicate URIs used in LDPR representations SHOULD be HTTP URLs.
+	<div id="ldpr-4_1_7" class="rule">4.1.7 Predicate URIs used in LDPR representations SHOULD be HTTP URLs.
 		 These predicate URIs MUST identify LDPRs whose representations are
 		retrievable. LDPR servers SHOULD provide an RDF Schema [[!RDF-SCHEMA]]
 		representation of these predicates.
@@ -343,7 +329,7 @@
 	</div>
 	</div>
 
-	<div id="ldpr-4_1_9" class="rule">4.1.9 LDPRs MUST use at least one RDF triple to represent a link
+	<div id="ldpr-4_1_8" class="rule">4.1.8 LDPRs MUST use at least one RDF triple to represent a link
 		(relationship) to another resource. In other words, having the source
 		resource’s URI as the subject and the target resource’s URI as the
 		object of the triple representing the link (relationship) is enough and
@@ -352,21 +338,21 @@
 		
 	<div class="ldp-issue">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/44">ISSUE-44</a></div>
-	4.1.9. is obscure or too restrictive
+	4.1.9.(now 4.1.8) is obscure or too restrictive
 	</div>
 	</div>
-	<div id="ldpr-4_1_10" class="rule">4.1.10 LDPR servers MAY support standard representations beyond those
+	<div id="ldpr-4_1_9" class="rule">4.1.9 LDPR servers MAY support standard representations beyond those
 		necessary to conform to this specification. These
 		could be other RDF formats, like N3 or NTriples, but non-RDF formats
 		like HTML [[!HTML401]] and JSON [[!RFC4627]] would be likely be common.
 	</div>
 		
-	<div id="ldpr-4_1_11" class="rule">4.1.11 LDPRs MAY be created, updated and deleted using methods not defined in
+	<div id="ldpr-4_1_10" class="rule">4.1.10 LDPRs MAY be created, updated and deleted using methods not defined in
 		this document, for example through application-specific means, SPARQL
 		UPDATE, etc. [[!SPARQL-UPDATE]], as long as those methods do not conflict with this specification's 
 		normative requirements.
 	</div>
-	<div id="ldpr-4_1_12" class="rule">4.1.12 LDPR server responses MUST use entity tags (either weak or strong 
+	<div id="ldpr-4_1_11" class="rule">4.1.11 LDPR server responses MUST use entity tags (either weak or strong 
 ones) as response <code>ETag</code> header values.
 	</div>
 	
@@ -391,7 +377,7 @@
 	Pagination for non-container resources
 	</div>
 
-	<div id="ldpr-4_1_13" class="rule">4.1.13 LDPR
+	<div id="ldpr-4_1_12" class="rule">4.1.12 LDPR
 		servers SHOULD enable simple creation and modification of LDPRs.
 		It is
 		common for LDPR servers to put restrictions on representations – for
@@ -1306,6 +1292,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-13 - ISSUE-49 Moved section 4.1.4 out of spec to the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Servers_should_serve_up_canonical_URLs">deployment guide</a>. (SS)</li>
 	<li>2013-05-08 - Removed closed issues 5, 7, 55 and 38 as the don't require edits. Added 64 and 65. (SS)</li>
 	<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>