ldp.html
changeset 334 8e9ad2d0e512
parent 333 3c2aaaea1f73
child 335 66c2dd386cfe
--- a/ldp.html	Tue Sep 17 14:10:41 2013 -0400
+++ b/ldp.html	Tue Sep 17 15:34:07 2013 -0400
@@ -279,23 +279,6 @@
 	exactly equals the LDPC's state.
 	<p></p></dd>
 	
-	<dt><dfn>Resource inlining</dfn></dt>
-	<dd>
-		The practice of responding to a HTTP GET request made to a request URI <var>R<sub>0</sub></var> with
-		a representation that includes the state of <var>R<sub>0</sub></var>, the <em>entire</em> state of resources accessed through
-		<em>other</em> request URI(s) <var>R<sub>1</sub></var>...<var>R<sub>n</sub></var>, <em>and assertions</em> from the server 
-		identifying the additional resources whose
-		entire state has been provided.
-		<var>R<sub>1</sub></var>...<var>R<sub>n</sub></var> identify the inlined resource(s).
-		See <a href="#ldpr-inlining" class="sectionRef"></a> for details.
-	<p></p></dd>
-	
-	<dt><dfn>Member inlining</dfn></dt>
-	<dd>A special case of <a title="Resource inlining">resource inlining</a>, where all members of a container on a given
-		page are inlined.  The response page may or may not include all of the container's members.
-		See <a href="#ldpc-inlining" class="sectionRef"></a> for details.
-	<p></p></dd>
-	
   </dl>
 
 <section id="conventions">
@@ -623,7 +606,7 @@
 		resource is too large to reasonably transmit its representation in a
 		single HTTP response. This will be especially true if the resource
 		representation includes many triples both from its own representation and
-		from the representations of any <a title="Resource inlining">inlined resources</a>. A client could anticipate that a resource will be too large -
+		from the representations of any of the member resources. A client could anticipate that a resource will be too large -
 		for example, a client tool that accesses defects may assume that an
 		individual defect will usually be of sufficiently constrained size
 		that it makes sense to request all of it at once, but that the
@@ -784,121 +767,8 @@
 	responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
 	response header for link relations using the header name of <code>Link</code> and link relation type <code>first</code> [[!RFC5988]].
 </div>
-</section>
-
-</section>
-
-<section id="ldpr-inlining">
-<h2>Resource Inlining: Representing Multiple Resources in a Response</h2>
-
-	<div class="atrisk"><p class="atrisktext">Feature At Risk</p>
-		<p>The LDP Working Group proposes incorporation of the features described in this section.</p>
-		<ul>
-		<li>The addition of <a>resource inlining</a> to save application latency
-		and server/network load in controlled environments.</li>
-		</ul>
-		<p>Feedback, both positive and negative, is invited by sending email to the mailing list 
-		in <a href="#sotd">Status of This Document</a>.</p>
-	</div>
-
-<section class="informative" id="ldpr-InliningIntro">
-<h3>Introduction</h3>
-	<p>Servers whose resources are relatively granular may wish to optimistically provide more information
-		in a response than what the client actually requested, in order to reduce the average number of client
-		application HTTP flows.  LDP provides some basic building blocks to enable
-		this, that implementations can re-use to build complete solutions, and they may serve as 
-		complete solutions in applications with sufficient controls on resource content.
-		These building blocks are <a>resource inlining</a> and <a>member inlining</a>.
-	</p>
-	
-	<p>LDP does not provide clients with any way to detect whether or not the server is capable of 
-		inlining (all its resources or any specific resource), nor does it provide clients 
-		with any way to influence which (if any) resources are inlined in any given response.
-	</p>
-	
-	<p>
-		Servers can return extra triples on any response, but fail to meet the definition of <a>resource inlining</a>, 
-		by either returning a subset of the other resource(s) triples or by failing to assert that
-		all triples were included (even through they were).  Clients might still find the extra
-		information useful, but the only way for clients to be sure they had all available 
-		information would be to make a HTTP <code>GET</code> request against all the other resource(s).
-		In some applications, knowing that these requests are unnecessary saves significant latency
-		and server/network load.
-	</p>
 </section> <!-- h3 -->
 
-<section class="informative" id="ldpr-InliningWarnings">
-<h3>Use with Care</h3>
-	<p>The building blocks LDP provides can only be safely used if certain assumptions hold.  
-	Said another way, resource inlining solves a subset of scenarios, not all scenarios in the general case &mdash;
-	so if you care about any of the following in a given application, your server should avoid returning
-	<em>any</em> triples beyond those found at the HTTP <code>Request-URI</code>.
-	</p>
-	<ul>
-	<li><p>
-		Provenance is lost: because RDF graphs from multiple HTTP resources are merged in the
-		response without attributing each statement to its originating graph (i.e. without quotation),
-		it is impossible for a client to reliably know which
-		triples came from which HTTP resource(s).  A general solution allowing quotation is
-		RDF Datasets; that is expected to be standardized independently, and can be used in these cases
-		once it is available.
-	</p></li>
-	<li><p>
-		The response may contain contradictions that are trivially obvious (or subtle), and those may or 
-		may not be a problem at the application level.  For a trivial example, two triples may have
-		identical subjects and predicates but different objects: "75F is too hot"; "75F is too cold".
-		Again, quotation via RDF Datasets (or any equivalent mechanism) is believed to provide a 
-		long term solution once standardized.
-	</p></li>
-	</ul>
-</section> <!-- h3 -->
-
-<section id="ldpr-InliningGET">
-<h3>HTTP GET</h3>
-	<p>In addition to the requirements set forth in other sections, 
-		LDPR servers that support <a>resource inlining</a>
-		must also follow the requirements in this section.</p>
-
-	<div id="ldpr-4_11_3_1" class="rule">4.11.3.1 LDPR servers that support <a>resource inlining</a> MUST 
-		include a <code>ldp:Page</code> resource in the representation describing the set of inlined resources, 
-		whether or not the representation contains subsequent pages.  The <code>ldp:Page</code> resource conceptually contains
-		metadata about the representation; it is usually not part of the HTTP resource's state, and its presence does not indicate that
-		the LDPR server supports <a href="#ldpr-Paging">paging</a> in general.  
-		LDPR servers that include the <code>ldp:Page</code> resource for inlining and also support 
-		paging MUST use the same <code>ldp:Page</code> resource for the triples required by both,
-		in order to minimize client code complexity.
-		The <code>ldp:Page</code> resource's triples are the LDP-defined means by which the servers communicate to LDP clients 
-		the set of HTTP resources whose state is included in a representation, allowing clients to avoid HTTP <code>GET</code>
-		requests for them.
-	</div>
-
-	<div id="ldpr-4_11_3_2" class="rule">4.11.3.2 LDPR servers that support <a>resource inlining</a> MUST 
-		include the <code>ldp:Page</code> resource described in <a href="#ldpr-4_11_3_1">section 4.11.3.1</a> 
-		one triple for each inlined resource, 
-		whose subject is the <code>ldp:Page</code> resource URI,
-		whose predicate is <code>ldp:inlinedResource</code>, and
-		whose object is the HTTP <code>Request-URI</code> of an inlined resource [[!HTTP11]].
-	</div>
-
-	<div id="ldpr-4_11_3_3" class="rule">4.11.3.3 LDPR clients SHOULD avoid making HTTP <code>GET</code> requests
-		against any resource whose HTTP <code>Request-URI</code> is the object of a triple of the form 
-		described in <a href="#ldpr-4_11_3_2">section 4.11.3.2</a>, unless there are application-specific
-		reasons for doing so.  Clients should note that by the time the representation is received, the actual state
-		of any inlined resource(s) may have changed due to subsequent requests.
-	</div>
-
-	<div id="ldpr-4_11_3_4" class="rule">4.11.3.4 LDPR clients MUST NOT assume that LDPR representations
-		lacking a <code>ldp:Page</code> resource or lacking the triple
-		described in <a href="#ldpr-4_11_3_2">section 4.11.3.2</a> contain all the triples for any resource(s)
-		listed in the representation whose HTTP <code>Request-URI</code> differs from 
-		the HTTP <code>Request-URI</code> used by the client.  
-		The representation might in fact contain all such triples, or some
-		subset of them, and that might or might not be completely adequate for the client's intended usage, but
-		an LDP client has no way to discern from such a representation which interpretation is accurate.
-	</div>
-
-</section>
-
 </section> <!-- h2 -->
 
 </section> <!-- h1 -->
@@ -1308,9 +1178,8 @@
 		or that are from the representations of the members (if they have RDF
 		representations). This allows a LDPC server to provide clients with
 		information about the members without the client having to do a <code>GET</code>
-		on each member individually.  See sections <a href="#ldpc-member_data">5.1.1 Container
-		Member Information</a>, <a href="#ldpr-inlining" class="sectionRef"></a>, and
-		<a href="#ldpc-inlining" class="sectionRef"></a> for additional details.
+		on each member individually.  See <a href="#ldpc-member_data">section 5.1.1 Container
+		Member Information</a> for additional details.
     </div>
 	<div id="ldpc-5_2_7" class="rule">5.2.7 The representation of a LDPC MUST have <code>rdf:type</code>
 		of <code>ldp:Container</code>, but it MAY have additional
@@ -1559,7 +1428,7 @@
 	</div>
 	    
     <div id="ldpc-5_5_3" class="rule">5.5.3 LDPC servers SHOULD NOT allow HTTP <code>PUT</code> requests
-		with <a title="Member inlining">inlined member</a> information in the request representation.
+		with member resource information in the request representation.
 		See section <a href="#ldpc-member_data">5.1.1 Container
 		Member Information</a> for additional details.
 	</div>
@@ -1651,85 +1520,9 @@
 	non-LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>).  For non-LDPRs that have this associated LDPR, an LDPC server MUST provide an HTTP <code>Link</code>
 	header whose target URI is the associated LDPR, and whose link relation type is 
 	<code>meta</code> [[!RFC5988]].</div>
-</section>
-
-<section id="ldpc-inlining">
-<h2>Member Inlining: Returning All of a Container Page's Members in a Response</h2>
-
-	<div class="atrisk"><p class="atrisktext">Feature At Risk</p>
-		<p>The LDP Working Group proposes incorporation of the features described in this section.</p>
-		<ul>
-		<li>The addition of <a>resource inlining</a> to save application latency
-		and server/network load in controlled environments.</li>
-		</ul>
-		<p>Feedback, both positive and negative, is invited by sending email to the mailing list 
-		in <a href="#sotd">Status of This Document</a>.</p>
-	</div>
-
-<section class="informative" id="ldpc-InliningIntro">
-<h3>Introduction</h3>
-	<p>One of the most commonly cited scenarios for resource inlining is to save clients enumerating a container of 
-		<i>m</i> members from having to perform <i>m+1</i> HTTP requests (or <i>m+p</i>, if the container
-		is paged into <i>p</i> pages).  The desire is to allow the server to reduce the number of HTTP
-		round-trips by returning some (perhaps all) members' content as part of the container's representation.
-		In addition to the general <a>resource inlining</a> mechanism useful
-		in cases where only a subset of the members' content is inlined, LDP also provides 
-		a predicate for the special case where <i>all</i> of a container's or page's members are inlined.
-		Rather than forcing the server to add a triple for each inlined member, forcing clients to
-		compare the list of inlined members against the set of members in the representation, 
-		and enlarging the representation needlessly,
-		a single triple can be used.  This is called <a>member inlining</a>.
-	</p>
-
-	<p>LDP does not provide clients with any way to detect whether or not the server is capable of 
-		resource inlining (all its resources or any specific resource), nor does it provide clients 
-		with any way to influence which (if any) resources are inlined in any given response.
-	</p>
+</section> <!-- h2 -->
 
-	<p>The inlining building blocks LDP provides can only be safely used if certain assumptions hold.
-		This is no less true for containers than for LDPRs in general.  
-		See the general <a href="#ldpr-InliningWarnings">cautions on resource inlining</a>.
-	</p>
-</section> <!-- h3 -->
-
-<section id="ldpc-InliningGET">
-<h3>HTTP GET</h3>
-	<p>In addition to the requirements set forth in other sections, 
-		LDPC servers that support <a>member inlining</a>,
-		and LDP clients aware of the same facility,
-		must also follow the requirements in this section.
-	</p>
-
-	<div id="ldpc-5_10_2_1" class="rule">5.10.2.1 LDPC representations that are <a title="member inlining">member inlined</a> MUST 
-		include a <code>ldp:Page</code> resource in the representation, whether or not the representation contains
-		multiple pages, as described in <a href="#ldpr-4_11_3_1">section 4.11.3.1</a>.  In addition to satisfying
-		those requirements, the representation MUST contain a triple
-		whose subject is the <code>ldp:Page</code> resource URI,
-		whose predicate is <code>ldp:membersInlined</code>, and
-		whose object is <code>"true"^^xsd:boolean</code>.
-		This is means by which the server communicates to LDP clients that they can avoid HTTP <code>GET</code>
-		requests for the members listed on the page.
-	</div>
-
-	<div id="ldpc-5_10_2_2" class="rule">5.10.2.2 LDPC clients SHOULD avoid making HTTP <code>GET</code> requests
-		against any members in a LDPC representation containing a <code>ldp:Page</code> resource with the triple
-		described in <a href="#ldpc-5_10_2_1">section 5.10.2.1</a>, unless there are application-specific
-		reasons for doing so.  Clients should note that by the time the representation is received, the actual state
-		of inlined members may have changed due to subsequent requests.
-	</div>
-
-	<div id="ldpc-5_10_2_3" class="rule">5.10.2.3 LDPC clients MUST NOT assume that LDPC representations
-		lacking a <code>ldp:Page</code> resource or lacking the triple
-		described in <a href="#ldpc-5_10_2_1">section 5.10.2.1</a> contain all the triples for all members
-		listed in the representation.  The representation might in fact contain all those triples, or some
-		subset of them, that might or might not be completely adequate for the client's intended usage, but
-		an LDP client has no way to discern from such a representation which interpretation is accurate.
-	</div>
-
-	</section>
-
-</section> <!-- h2 -->
-</section>
+</section> <!-- h1 -->
 
 <section>
 <h1>HTTP Header Definitions</h1>
@@ -1820,6 +1613,7 @@
 
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote>  -->
 <ul>
+	<li>2013-09-17 - Removed "at-risk" inlining feature from spec, <a href="https://www.w3.org/2012/ldp/track/actions/98">ACTION-98</a> (SS)</li>
 	<li>2013-09-17 - Fixed vanishing section ref problem (SS)</li>
 	<li>2013-08-19 - Basic preparation for edits unto LC draft (SS)</li>
 </ul>