Added section on Link: headers and content negotiation (ISSUE 416)
authorGraham Klyne
Mon, 19 Nov 2012 12:58:00 +0000
changeset 4793 7f6c1a541631
parent 4789 9c24773fd6c7
child 4794 203add198c0f
Added section on Link: headers and content negotiation (ISSUE 416)
paq/prov-aq.html
--- a/paq/prov-aq.html	Mon Nov 19 12:17:17 2012 +0000
+++ b/paq/prov-aq.html	Mon Nov 19 12:58:00 2012 +0000
@@ -356,7 +356,7 @@
         These particular cases are selected as corresponding to primary current web protocol and data formats.  Similar approaches  may be possible for other protocols or resource formats.  Finally, in <a href="#arbitrary-data" class="sectionRef"></a>, we discuss the case of a resource in an unspecified format which has been provided by some means other than HTTP.
       </p>
       <p>
-        The mechanisms described here are intended to allow a provider to supply information that may assist a client in finding related provenance information.  While a provider should avoid giving spurious information, there are no fixed semantics, particularly when multiple resources are indicated, and a client should not assume that a specific given provenance-uri will yield information about a specific given target-uri.  In the general case, a client presented with multiple provenance-uris and multiple target-uris should look at all of the provenance-uris for information about any or all of the target-uris.
+        The mechanisms described here are intended to allow a provider to supply information that may assist a client in finding related provenance information, and the provenance information itself should explicitly identify the target resources it describes.  While a provider should avoid giving spurious information, there are no fixed semantics, particularly when multiple resources are indicated, and a client should not assume that a specific given provenance-uri will yield information about a specific given target-uri.  In the general case, a client presented with multiple provenance-uris and multiple target-uris should look at all of the provenance-uris for information about any or all of the target-uris.
       </p>
       <p>
         The mechanisms specified for use with HTTP and HTML are similar to those proposed by POWDER [[POWDER-DR]] (sections <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/#assoc-markup" class="externalRef">4.1.1</a> and <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/#httplink" class="externalRef">4.1.3</a>).
@@ -390,19 +390,63 @@
 
         <section>
           <h2>Specifying Provenance Services</h2>
-            <p>
-              The resource provider may indicate that provenance information about the resource is provided by a <a class="internalDFN">provenance service</a>. This is done through the use of a <code>hasProvenanceService</code> link relation type following the same pattern as above:
-            </p>
-            <pre class="pattern">
+          <p>
+            The resource provider may indicate that provenance information about the resource is provided by a <a class="internalDFN">provenance service</a>. This is done through the use of a <code>hasProvenanceService</code> link relation type following the same pattern as above:
+          </p>
+          <pre class="pattern">
 Link: <cite>provenance-service-URI</cite>; rel="http://www.w3.org/ns/prov#hasProvenanceService"; anchor="<cite>target-URI</cite>"</pre>
-            <p>
-              The <code>hasProvenanceService</code> link identifies the <a class="internalDFN">service-URI</a>.  Dereferencing this URI yields a service description that provides further information to enable a client to determine a <a class="internalDFN">provenance-URI</a> or retrieve <a class="internalDFN">provenance information</a> for a <a class="internalDFN">resource</a>; see <a href="#provenance-services" class="sectionRef"></a> for more details.
-            </p>
-            <p>
-            There may be multiple <code>hasProvenanceService</code> link header fields, and these may appear in an HTTP response together with <code>hasProvenance</code> link header fields (though, in simple cases, we anticipate that <code>hasProvenance</code> and <code>hasProvenanceService</code> link relations will not be used together).
+          <p>
+            The <code>hasProvenanceService</code> link identifies the <a class="internalDFN">service-URI</a>.  Dereferencing this URI yields a service description that provides further information to enable a client to determine a <a class="internalDFN">provenance-URI</a> or retrieve <a class="internalDFN">provenance information</a> for a <a class="internalDFN">resource</a>; see <a href="#provenance-services" class="sectionRef"></a> for more details.
           </p>
+          <p>
+          There may be multiple <code>hasProvenanceService</code> link header fields, and these may appear in an HTTP response together with <code>hasProvenance</code> link header fields (though, in simple cases, we anticipate that <code>hasProvenance</code> and <code>hasProvenanceService</code> link relations will not be used together).
+        </p>
         </section>
 
+        <section>
+          <h2>Content negotiation, redirection and Link: headers</h2>
+          <p>
+            When performing content negotiation for a resource, it is common for HTTP 302 or 303 redirect response codes to be used to direct a client to an appropriately-formatted resource.  When accessing a resource for which provenance information is available, link headers SHOULD be included with the response to the final redirected request, and not on the intermediate 303 responses.  (When accessing a resource from a browser using Javascript, the intermediate 303 responses are usually handled transparently by the browser and are not visible to the HTTP client code.) 
+          </p>
+          <p>
+            Following content negotiation, any link to provenance information returned refers to the resource whose URI is used in the corresponding HTTP request, or the given anchor parameter if that is different. (The provenance information itself may also refer to other resources; see the discussion at the start of <a href="#locating-provenance-information" class="sectionRef"></a>.)
+          </p>
+          <p>
+            An example transaction using content negotiation and redirection might look like this (where <code>C:</code> and <code>S:</code> prefixes indicate client and server emitted data respectively):
+          </p>
+          <pre class="pattern">
+            C: GET /resource/
+            C: Host: http://example.com/
+            C: Accept: text/html
+            
+            S: 302 Found
+            S: Location: /resource/content.html
+            S: Vary: Accept
+            S:
+            S: HTML content for http://example.com/resource/ 
+            S: is available at http://example.com/resource/content.html
+            
+            C: GET /resource/content.rdf
+            C: Host: http://example.com/
+            C: Accept: text/html
+            
+            S: 200 OK
+            S: Content-type: text/html
+            S: Vary: Accept
+            S: Link: &lt;http://example.com/resource/provenance/&gt;; 
+                     rel="http://www.w3.org/ns/prov#hasProvenance"; 
+                     anchor="http://example.com/resource/"
+            S:
+            S: &lt;html ...&gt;
+            S:  :
+            S: &lt;/html&gt;
+          </pre>
+        </section>
+
+
+
+
+
       </section>
 
       <section>