changes motivated by joe ross's comments
authorJohn Arwe
Mon, 12 May 2014 07:34:25 -0400
changeset 600 67d13fb3a21f
parent 599 62c3b915d045
child 601 5fc4b4b9efc2
changes motivated by joe ross's comments
ldp.html
--- a/ldp.html	Thu May 08 16:40:54 2014 +0200
+++ b/ldp.html	Mon May 12 07:34:25 2014 -0400
@@ -539,7 +539,7 @@
 		with a target URI of <code>http://www.w3.org/ns/ldp#Resource</code>, and
 		a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
 		in all responses to requests made 
-		to the LDPR's HTTP <code>Request-URI</code> [[!RFC5988]]. 
+		to an LDPR's HTTP <code>Request-URI</code> [[!RFC5988]]. 
 	</h2></section><!-- Was 4.2.10 / #ldpr-4_2_10 -->
 	<blockquote>
 		<p>
@@ -548,10 +548,10 @@
 		on a specific resource in a way that clients can inspect dynamically at run-time.   
 		This is <strong>not</strong> equivalent to the
 		presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in an LDP-RS.
-		The presence of this header asserts that the server complies with the LDP specification's constraints on 
+		The presence of the header asserts that the server complies with the LDP specification's constraints on 
 		HTTP interactions with LDPRs, that is
-		it asserts that the resource <a href="#ldpr-gen-etags">has Etags</a>, <a href="#ldprs-gen-rdf">has an RDF representation</a>, and so on,
-		which is not true of all Web resources served as RDF media types.
+		it asserts that the resource <a href="#ldpr-gen-etags">has Etags</a>, <a href="#ldpr-options-must">supports OPTIONS</a>, and so on,
+		which is not true of all Web resources.
 		</p>
 		<p>
 		Note: 
@@ -629,7 +629,7 @@
 		<a title="LDP server">LDP servers</a> MUST
 		replace the entire persistent state of the identified resource with
 		the entity representation in the body of the request. 
-		<a title="LDP server">LDP servers</a> MAY ignore server managed properties such as <code>dcterms:modified</code> 
+		<a title="LDP server">LDP servers</a> MAY ignore server-managed properties such as <code>dcterms:modified</code> 
 		and <code>dcterms:creator</code> if they are not under
 		client control. Any <a title="LDP server">LDP servers</a> that wish
 		to support a more sophisticated merge of data provided by the client
@@ -646,7 +646,7 @@
 		If an otherwise valid HTTP <code>PUT</code> request is received 
 		that attempts to change properties the server does not allow clients to modify, 
 		<a title="LDP server">LDP servers</a> MUST 
-		respond with a 4xx range status code (typically
+		fail the request by responding with a 4xx range status code (typically
 		409 Conflict). 
 		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
 		information about which properties could not be
@@ -656,7 +656,10 @@
 	<blockquote>
 		Non-normative note: Clients might provide properties equivalent to those already in the resource's state,
 		e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the 
-		server-controlled properties are identical on the GET response and the subsequent PUT request.
+		server-managed properties 
+		are identical on the GET response and the subsequent PUT request.
+		This is in contrast to other cases like write-once properties that the server does not allow clients to modify once set; 
+		write-once properties are under client control, they are not <a href="#ldpr-put-replaceall">server-managed</a>.
 	</blockquote>
 	
 	<section id="ldprs-put-failed"><h2 class="normal">
@@ -853,10 +856,14 @@
 <section id="ldprs-HTTP_GET">
 <h2>HTTP GET</h2>
 	<section id="ldprs-get-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
-		representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> [[!turtle]].
+		representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> whenever HTTP content negotiation
+		does not force another outcome [[!turtle]].  In other words, if the server receives a <code>GET</code> request whose <code>Request-URI</code>
+		identifies a <a title="">LDP-RS</a>, and either <code>text/turtle</code> has the highest relative quality
+		factor (<code>q=</code> value) in the 
+		Accept request header or that header is absent, then an <a title="">LDP server</a> has to respond with Turtle.
 	</h2></section><!-- Was 4.3.3 / #ldpr-4_3_3 -->
 
-	<section id="ldprs-get-jsonld"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD provide a <code>application/ld+json</code>
+	<section id="ldprs-get-jsonld"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD offer a <code>application/ld+json</code>
 		representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> [[!JSON-LD]].
 	</h2></section><!-- new -->
 
@@ -1575,16 +1582,15 @@
 <section id="ldpc-HTTP_OPTIONS">
 <h2>HTTP OPTIONS</h2>
 	<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPCs.
+		Note that support for this method is required for LDPCs, since <a href="#ldpr-HTTP_OPTIONS">it is required for LDPRs</a> and 
+		<a href="#ldpc-isldpr">LDPCs adhere to LDP-RS requirements</a>.
 		</p>
 
-	<section id="ldpc-options-linkmetahdr"><h2 class="normal">When a LDPC server creates an 
-	<a title="Linked Data Platform Non-RDF Source">LDP-NR</a> (for example, one whose 
-	representation was HTTP <code>POST</code>ed to the LDPC) 
-	the LDP server might create an associated <a title="Linked Data Platform RDF Source">LDP-RS</a> 
-	to contain data about the non-LDPR (see <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>).  
-	For LDP-NRs that have this associated LDP-RS, a LDPC server MUST provide an HTTP <code>Link</code>
-	header whose target URI is the associated LDP-RS, and whose link relation type is 
-	<code>describedby</code> [[!RFC5988]].
+	<section id="ldpc-options-linkmetahdr"><h2 class="normal">
+	When responding to requests whose <code>request-URI</code> is a 
+	<a href="#ldpc-post-createbinlinkmetahdr">LDP-NR with an associated LDP-RS</a>, 
+	a LDPC server MUST provide the same HTTP <code>Link</code>
+	response header as is <a href="#ldpc-post-createbinlinkmetahdr">required in the create response</a>.
 	</h2></section><!-- Was 5.9.2 / #ldpc-5_9_2 -->
 </section> <!-- h2 -->
 </section> <!-- ldpc-container -->
@@ -2367,6 +2373,7 @@
 <h2>Detailed history</h2>
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> -->
 <ul>
+	<li>2014-05-09 - Respond to Joe Ross's LC2 comments (JA) </li>
 	<li>2014-04-28 - Added usage for ldp:NonLDPSource (SS) </li>
 	<li>2014-04-28 - Clarify MUST etags on responses with representations and HEAD (SS) </li>
 	<li>2014-04-17 - Add should for json-ld per today's WG resolution (JA) </li>