Should return Turtle if Accept is absent, JSON-LD required (at risk), clarify creates
--- a/ldp.html Mon Sep 08 13:27:20 2014 -0400
+++ b/ldp.html Mon Sep 08 14:29:43 2014 -0400
@@ -253,6 +253,10 @@
</li>
<li>The requirement that LDP clients be <a href="#atrisk-paging">paging-aware</a>.
</li>
+ <li>JSON-LD as a required <a href="#atrisk-ldpr-jsonld">response representation</a> and <a href="#atrisk-ldpc-jsonld">new member representation</a>.
+ </li>
+ <li>Support for <a href="#atrisk-indirect-containers">indirect containers</a>.
+ </li>
</ol>
</section>
@@ -663,7 +667,7 @@
</h2></section><!-- Was 4.5.1 / #ldpr-4_5_1 -->
<section id="ldpr-put-simpleupdate"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to update resources without
- requiring detailed knowledge of server-specific constraints.
+ requiring detailed knowledge of <a href="#ldpr-gen-pubclireqs">server-specific constraints</a>.
This is a consequence of the requirement to enable simple creation and modification of LDPRs.
</h2></section><!-- Was 4.5.7 / #ldpr-4_5_7 -->
@@ -868,6 +872,7 @@
<div class="atrisk" id="atrisk-paging"><p class="atrisktext">Feature At Risk</p>
<p>The LDP Working Group proposes incorporation of the following clause to make LDP clients paging aware:</p>
+ </div>
<section id="ldpr-cli-paging"><h2 class="normal">
<a title="LDP client">LDP clients</a> SHOULD
be capable of processing successful HTTP <code>GET</code> responses formed by a LDP server
@@ -875,24 +880,35 @@
representation [[!LDP-PAGING]].
</h2>
</section>
- </div>
</section> <!-- ldprs-general -->
<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> 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.
+ <section id="ldprs-get-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST offer a <code>text/turtle</code>
+ representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> [[!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 offer a <code>application/ld+json</code>
+ <div class="atrisk" id="atrisk-ldpr-jsonld"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the following clause (changed from Should to Must):</p>
+ </div>
+ <section id="ldprs-get-jsonld"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
+ 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 -->
+ <section id="ldprs-get-conneg"><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> whenever HTTP content negotiation
+ does not force another outcome and the <code>Accept</code> request header is present.
+ 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 <code>text/turtle</code> has the highest relative quality
+ factor (<code>q=</code> value) in the
+ Accept request header, then an <a title="">LDP server</a> has to respond with Turtle,
+ even if other media types share the highest relative quality factor.
+ If the <code>Accept</code> request header is absent,
+ then <a title="LDP server">LDP servers</a> SHOULD respond with <code>text/turtle</code>.
+ </h2></section><!-- Was 4.3.3 / #ldpr-4_3_3 -->
+
</section> <!-- ldprs-HTTP_GET -->
</section> <!-- ldprs RDF Source-->
@@ -1553,7 +1569,8 @@
</blockquote>
</section>
- <section id="ldpc-post-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
+ <section id="ldpc-post-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a>
+ that allow creation of <a title="Linked Data Platform RDF Source">LDP-RSs</a> via POST MUST
allow clients to create new members by enclosing a request entity body with a
<code>Content-Type</code> request header whose value is <code>text/turtle</code> [[!turtle]].
</h2></section><!-- Was 5.4.5 / #ldpc-5_4_5 -->
@@ -1562,10 +1579,12 @@
to determine the request representation's format when the request has an entity body.
</h2></section><!-- Was 5.4.6 / #ldpc-5_4_6 -->
- <section id="ldpc-post-rdfnullrel"><h2 class="normal">In RDF representations, <a title="LDP server">LDP servers</a> MUST interpret the null relative
- URI for the subject of triples in the LDPR representation in the
+ <section id="ldpc-post-rdfnullrel"><h2 class="normal"><a title="LDP server">LDP servers</a>
+ creating a <a title="Linked Data Platform RDF Source">LDP-RS</a> via POST MUST
+ interpret the null relative
+ URI for the subject of triples in the LDP-RS representation in the
request entity body as identifying the entity in the request body.
- Commonly, that entity is the model for the “to be created” LDPR, so
+ Commonly, that entity is the model for the "to be created" LDPR, so
triples whose subject is the null relative URI result in
triples in the created resource whose subject is the created
resource.
@@ -1620,10 +1639,15 @@
specifications such as LDP.
</h2></section><!-- Was 5.4.13 / #ldpc-5_4_13 -->
- <section id="ldpc-post-jsonld"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD
+ <div class="atrisk" id="atrisk-ldpc-jsonld"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the following clause (changed from Should to Must):</p>
+ </div>
+ <section id="ldpc-post-jsonld"><h2 class="normal"><a title="LDP server">LDP servers</a>
+ that allow creation of <a title="Linked Data Platform RDF Source">LDP-RSs</a> via POST MUST
allow clients to create new members by enclosing a request entity body with a
<code>Content-Type</code> request header whose value is <code>application/ld+json</code> [[!JSON-LD]].
</h2></section><!-- new -->
+
</section>
@@ -2527,8 +2551,8 @@
<ul>
<li>Indirect containers are AT RISK</li>
<li>Turtle is no longer required for an LDP-RS when the Accept header is absent</li>
- <li>JSON-LD is required for an LDP-RS, AT RISK</li>
- <li>Changed the link relation used to articulate request constraints that a client has violated</li>
+ <li>JSON-LD is required for an LDP-RS and LDPC create via POST, AT RISK</li>
+ <li>Changed the link relation used to articulate request constraints that a client has likely violated</li>
</ul>
<h2>Detailed history</h2>
@@ -2538,6 +2562,7 @@
<blockquote><em><a href="http://www.w3.org/TR/2014/WD-ldp-20140916">Last Call Working Draft 3</a></em></blockquote> -->
<ul>
+ <li>2014-09-08 - Should return Turtle if Accept is absent, JSON-LD required (at risk), clarify creates (JA) </li>
<li>2014-09-08 - Changed the constraints link relation to ldp#constrainedBy, per today's mtg resolution (JA) </li>
<li>2014-09-08 - Clarify that Turtle/JSON-LD on LDPC POST are required only when the semantic is "create new member" (JA) </li>
<li>2014-09-08 - Constraints 4xx responses remind them to choose context URI consciously (JA) </li>