--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/Test Cases/LDP Test Cases.html Thu Apr 25 16:07:10 2013 +0200
@@ -0,0 +1,1104 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta content="text/html; charset=utf-8" http-equiv="content-type" />
+ <title>LDP Test Cases</title>
+ <link href="http://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet" type="text/css"
+ charset="utf-8" />
+ </head>
+ <body>
+ <p>
+ <a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C" /></a>
+ </p>
+
+ <h1>Linked Data Platform 1.0 Test Cases</h1>
+
+ <h2>Table of Contents</h2>
+ <p><a href="#Tests-LDPRs"><strong>Tests for L</strong><strong>DP</strong></a><strong><a
+ href="#Tests-LDPRs">Rs</a>:</strong></p>
+ <ul>
+ <li><a href="#TC-R1">TC-R1. GET on an LDPR</a></li>
+ <li><a href="#TC-R2">TC-R2. GET on an LDPR without content type</a></li>
+ <li><a href="#TC-R3">TC-R3. GET on a non-existing LDPR</a></li>
+ <li><a href="#TC-R4">TC-R4. PUT on an LDPR</a></li>
+ <li><a href="#TC-R5">TC-R5. PUT on an LDPR without matching ETags</a></li>
+ <li><a href="#TC-R6">TC-R6. DELETE on an LDPR</a></li>
+ <li><a href="#TC-R7">TC-R7. HEAD on an LDPR</a></li>
+ </ul>
+ <p><a href="#Tests-LDPCs"><strong>Tests for L</strong><strong>DP</strong></a><strong><a
+ href="#Tests-LDPCs">Cs</a>:</strong></p>
+ <ul>
+ <li><a href="#TC-C1">TC-C1. GET on an LDPC</a></li>
+ <li><a href="#TC-C2">TC-C2. GET on an LDPC without content type</a></li>
+ <li><a href="#TC-C3">TC-C3. GET on a non-existing LDPC</a></li>
+ <li><a href="#TC-C4">TC-C4. PUT on an LDPC</a></li>
+ <li><a href="#TC-C5">TC-C5. PUT on an LDPC without matching ETags</a></li>
+ <li><a href="#TC-C6">TC-C6. DELETE on an LDPC</a></li>
+ <li><a href="#TC-C7">TC-C7. DELETE on an LDPR in an LDPC</a></li>
+ <li><a href="#TC-C8">TC-C8. HEAD on an LDPC</a></li>
+ <li><a href="#TC-C9">TC-C9. POST an LDPR on an LDPC</a></li>
+ </ul>
+ <p><a href="#Feedback">Feedback to recommendation</a></p>
+ <p><a href="#EditorNotes">Editor TODOs and notes</a></p>
+ <hr />
+ <h2>Introduction</h2>
+ <p>This document describes...</p>
+ <h2>Design issues </h2>
+ <h3>Generic vs domain-specific servers</h3>
+ <p>There will be two types of systems implementing the LDP specification:</p>
+ <ul>
+ <li>Generic RDF storage systems that allow interacting with their
+ resources by means of the LDP specification. These servers do not impose
+ any restriction on LDPRs.</li>
+ <li>Systems exposing their data using the LDP specification. These systems
+ impose restrictions on LDPRs since they have an underlying business
+ logic and data model.</li>
+ </ul>
+ <p>In order to cover both types of systems, we do not provide concrete input
+ data in the test suite. It is up to the evaluator to define concrete input
+ data for a certain system. Evaluators must include these input data along
+ with the results when reporting the results of a certain system.</p>
+ <h3>Protocol evaluation vs data evaluation</h3>
+ <p>The LDP specification includes restrictions on LDP servers at the
+ protocol level and at the data level. Currently, the restrictions at the
+ data level are minimal and servers are not forced to have a concrete
+ behaviour when processing LDPR representations. Therefore, the test suite
+ evaluates LDP servers at a protocol level; the only exception is in the
+ case of LDPCs, since they are required to include an rdf.type statement in
+ their representation.</p>
+ <p>It is out of the scope of the test suite to test LDP servers in terms of
+ the restrictions imposed by their underlying data models.</p>
+ <h3>Test suite coverage</h3>
+ <p>This test suite only covers those absolute requirements present in the
+ LDP specification (as stated by the use of the MUST key word). This set of
+ absolute requirements identifies the core subset of the LDP specification,
+ LDP Core from now on, and any LDP server that satisfies these absolute
+ requirements will be an LDP Core conformant server.</p>
+ <p>It is out of the scope of this test suite to test other levels of
+ conformance in terms of optional capabilities (e.g., paging).</p>
+ <h3>Separation of results and assertions</h3>
+ <p>Instead of defining expected results for tests, which will be dependent
+ on concrete implementations, we have defined the assertions to be made
+ over test results. In order to successfully pass a test all the assertions
+ must be satisfied.</p>
+ <p>Separating test outputs and assertions has other benefits: it makes
+ simpler to report tool results and assertions can be made by a third
+ party.</p>
+ <h2><a id="Tests-LDPRs"></a>Tests for LDPRs</h2>
+ <p>These tests involve only LDPRs.</p>
+ <h3><a id="TC-R1">TC-R1. GET on an LDPR</a></h3>
+ <h4>Related specification</h4>
+ <p><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a>:</em></p>
+ <ul>
+ <li>4.1.12 LDPR server responses MUST use entity tags (either weak or
+ strong ones) as response ETag header values. </li>
+ <li>4.2.1 LDPR servers MUST support the HTTP GET Method for LDPRs. </li>
+ <li>4.2.2 LDPR servers MUST provide a text/turtle representation of the
+ requested LDPR. </li>
+ </ul>
+ <h4>Input</h4>
+ <ul>
+ <li> <em><LDPR URI></em>. The URI of an LDPR. </li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPR at <LDPR URI></li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>GET <LDPR URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 GET></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 GET> (GET correct): </li>
+ <li>
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[entity-header].Content-Type = text/turtle</li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-R2">TC-R2. GET on an LDPR without content type</a></h3>
+ <h4>Related specification</h4>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>4.2.3 [...] If the client does not indicate a preference, text/turtle
+ MUST be returned. </li>
+ </ul>
+ <h4>Input</h4>
+ <ul>
+ <li> <em><LDPR URI></em>. The URI of an LDPR. </li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPR at <LDPR URI></li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>GET <LDPR URI></li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 GET></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 GET> (GET correct): </li>
+ <li>
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[entity-header].Content-Type = text/turtle</li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-R3">TC-R3. GET on a non-existing LDPR</a></h3>
+ <h4>Related specification</h4>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>4.5.1 LDPR servers MUST remove the resource identified by the
+ Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on
+ the same Request-URI MUST result in a 404 (Not found) or 410 (Gone)
+ status code.</li>
+ </ul>
+ <h4>Input</h4>
+ <ul>
+ <li> <em><LDPR URI></em>. The URI of a non-existing LDPR. </li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server does not contain an LDPR at <LDPR URI></li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>GET <LDPR URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 GET></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 GET> (GET incorrect): </li>
+ <li>
+ <ul>
+ <li>[Status-Line].Status-Code = 404 or 410</li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-R4">TC-R4. PUT on an LDPR</a></h3>
+ <h4>Related specification</h4>
+ <p><em><a target="_blank" href="http://tools.ietf.org/html/rfc2616">Hypertext
+ Transfer Protocol -- HTTP/1.1</a>:</em></p>
+ <ul>
+ <li>3.11 [...] An entity tag MUST be unique across all versions of all
+ entities associated with a particular resource.</li>
+ </ul>
+ <h4>Input </h4>
+ <ul>
+ <li> <em><LDPR URI></em>. The URI of an LDPR</li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPR at <LDPR URI></li>
+ <li>The LDPR at <LDPR URI> allows PUT</li>
+ <li>The LDP server allows updating in the LDPR the current representation
+ at <LDPR URI></li>
+ <li>The LDP server does not desire that the request be applied to a
+ different URI</li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>GET <LDPR URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ <li>PUT <LDPR URI>
+ <ul>
+ <li>[request-header].If-Match = <Response GET
+ 1>.[response-header].ETag</li>
+ <li>[message-body] = <Response GET 1>.[message-body]</li>
+ </ul>
+ </li>
+ <li>GET <LDPR URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em><Response 1 GET></em></li>
+ <li> <em> <Response 2 PUT></em></li>
+ <li> <em> <Response 3 GET></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 GET> (GET correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[entity-header].Content-Type = text/turtle</li>
+ </ul>
+ </li>
+ <li>Assert <Response 2 PUT> (PUT correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ </ul>
+ </li>
+ <li>Assert <Response 3 GET> (GET correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[entity-header].Content-Type = text/turtle</li>
+ </ul>
+ </li>
+ <li>Assert <Response 3 GET> (LDPR updated):
+ <ul>
+ <li>[response-header].ETag != <Response 1
+ GET>.[response-header].ETag</li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-R5">TC-R5. PUT on an LDPR without matching ETags</a></h3>
+ <h4>Related specification</h4>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>4.4.2 [...] LDPR servers MUST respond with status code 412 (Condition
+ Failed) if ETags fail to match if there are no other errors with the
+ request. </li>
+ </ul>
+ <h4>Input </h4>
+ <ul>
+ <li> <em><LDPR URI></em>. The URI of an LDPR</li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPR at <LDPR URI></li>
+ <li>The LDPR at <LDPR URI> allows PUT</li>
+ <li>The LDP server allows updating in the LDPR the current representation
+ at <LDPR URI></li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>GET <LDPR URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ <li>PUT <LDPR URI>
+ <ul>
+ <li>[request-header].If-Match = <Response GET
+ 1>.[response-header].ETag + 'M'</li>
+ <li>[message-body] = <Response GET 1>.[message-body]</li>
+ </ul>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 GET></em></li>
+ <li> <em> <Response 2 PUT></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 GET> (GET correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[entity-header].Content-Type = text/turtle</li>
+ </ul>
+ </li>
+ <li>Assert <Response 2 PUT> (PUT correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 412</li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-R6">TC-R6. DELETE on an LDPR</a></h3>
+ <h4>Related specification</h4>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>4.5.1 LDPR servers MUST remove the resource identified by the
+ Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on
+ the same Request-URI MUST result in a 404 (Not found) or 410 (Gone)
+ status code.</li>
+ </ul>
+ <h4>Input</h4>
+ <ul>
+ <li> <em><LDPR URI></em>. The URI of an LDPR. </li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPR at <LDPR URI></li>
+ <li>The LDPR at <LDPR URI> allows DELETE</li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>DELETE <LDPR URI></li>
+ <li>GET <LDPR URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 DELETE></em></li>
+ <li> <em> <Response 2 GET></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 DELETE> <Response 2 GET> (DELETE
+ correct): </li>
+ <li>
+ <ul>
+ <li><Response 1 DELETE>.[Status-Line].Status-Code = 200 or 204 and
+ <Response 2 GET>.[Status-Line].Status-Code = 404 or 410<strong>
+ </strong></li>
+ <li>or </li>
+ <li><Response 1 DELETE>.[Status-Line].Status-Code = 2xx (except
+ 200 and 204)
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-R7">TC-R7. HEAD on an LDPR</a></h3>
+ <h4>Related specification</h4>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>4.6.1 LDPR servers MUST support the HTTP HEAD method.</li>
+ <li>4.6.2 LDPR servers MUST indicate their support for HTTP Methods by
+ responding to a HTTP HEAD request on the LDPR’s URL with the HTTP Method
+ tokens in the HTTP response header “Allow”. </li>
+ </ul>
+ <p><a target="_blank" href="http://tools.ietf.org/html/rfc2616"><em>Hypertext
+ Transfer Protocol -- HTTP/1.1</em></a>:</p>
+ <ul>
+ <li>9.4 The HEAD method is identical to GET except that the server MUST
+ NOT return a message-body in the response.</li>
+ </ul>
+ <h4>Input</h4>
+ <ul>
+ <li> <em><LDPR URI></em>. The URI of an LDPR. </li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPR at <LDPR URI></li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>HEAD <LDPR URI></li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 HEAD></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 HEAD> (HEAD correct): </li>
+ <li>
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx<strong> </strong></li>
+ <li>[entity-header].Allow exists</li>
+ <li>[message-body] not exists</li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h2><a id="Tests-LDPCs"></a>Tests for LDPCs</h2>
+ <p>These tests involve LDPCs and LDPRs.</p>
+ <h3><a id="TC-C1">TC-C1. GET on an LDPC</a></h3>
+ <h4>Related specification</h4>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>4.1.12 LDPR server responses MUST use entity tags (either weak or
+ strong ones) as response ETag header values. </li>
+ <li>4.2.1 LDPR servers MUST support the HTTP GET Method for LDPRs. </li>
+ <li>4.2.2 LDPR servers MUST provide a text/turtle representation of the
+ requested LDPR. </li>
+ <li>5.2.7 The representation of a LDPC MUST have rdf:type of
+ ldp:Container, but it MAY have additional rdf:types. </li>
+ </ul>
+ <h4>Input</h4>
+ <ul>
+ <li> <em><LDPC URI></em>. The URI of an LDPC. </li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPC at <LDPC URI></li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>GET <LDPC URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 GET></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 GET> (GET resource correct): </li>
+ <li>
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[entity-header].Content-Type = text/turtle</li>
+ </ul>
+ </li>
+ <li>Assert <Response 1 GET> (GET container correct):</li>
+ <li>
+ <ul>
+ <li>[message-body] contains rdf:type ldp:Container</li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-C2">TC-C2. GET on an LDPC without content type</a></h3>
+ <h4>Related specification</h4>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>4.2.3 [...] If the client does not indicate a preference, text/turtle
+ MUST be returned. </li>
+ </ul>
+ <h4>Input</h4>
+ <ul>
+ <li> <em><LDPC URI></em>. The URI of an LDPC. </li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPC at <LDPC URI></li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>GET <LDPC URI></li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 GET></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 GET> (GET resource correct): </li>
+ <li>
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[entity-header].Content-Type = text/turtle</li>
+ </ul>
+ </li>
+ <li>Assert <Response 1 GET> (GET container correct):</li>
+ <li>
+ <ul>
+ <li>[message-body] contains rdf:type ldp:Container</li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-C3">TC-C3. GET on a non-existing LDPC</a></h3>
+ <h4>Related specification</h4>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>4.5.1 LDPR servers MUST remove the resource identified by the
+ Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on
+ the same Request-URI MUST result in a 404 (Not found) or 410 (Gone)
+ status code.</li>
+ </ul>
+ <h4>Input</h4>
+ <ul>
+ <li> <em><LDPC URI></em>. The URI of a non-existing LDPC. </li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server does not contain an LDPC at <LDPC URI></li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>GET <LDPC URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 GET></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 GET> (GET incorrect): </li>
+ <li>
+ <ul>
+ <li>[Status-Line].Status-Code = 404 or 410</li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-C4">TC-C4. PUT on an LDPC</a></h3>
+ <h4>Related specification</h4>
+ <p><em><a target="_blank" href="http://tools.ietf.org/html/rfc2616">Hypertext
+ Transfer Protocol -- HTTP/1.1</a>:</em></p>
+ <ul>
+ <li>3.11 [...] An entity tag MUST be unique across all versions of all
+ entities associated with a particular resource.</li>
+ </ul>
+ <h4>Input </h4>
+ <ul>
+ <li><em> <LDPC URI></em>. The URI of an LDPC</li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPC at <LDPC URI></li>
+ <li>The LDPC at <LDPC URI> allows PUT</li>
+ <li>The LDP server allows updating in the LDPC the current representation
+ at <LDPC URI></li>
+ <li>The LDP server does not desire that the request be applied to a
+ different URI</li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>GET <LDPC URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ <li>PUT <LDPC URI>
+ <ul>
+ <li>[request-header].If-Match = <Response GET
+ 1>.[response-header].ETag</li>
+ <li>[message-body] = <Response GET 1>.[message-body]</li>
+ </ul>
+ </li>
+ <li>GET <LDPC URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 GET></em></li>
+ <li> <em> <Response 2 PUT></em></li>
+ <li> <em> <Response 3 GET></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 GET> (GET resource correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[entity-header].Content-Type = text/turtle</li>
+ </ul>
+ </li>
+ <li>Assert <Response 1 GET> (GET container correct):
+ <ul>
+ <li>[message-body] contains rdf:type ldp:Container</li>
+ </ul>
+ </li>
+ <li>Assert <Response 2 PUT> (PUT correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ </ul>
+ </li>
+ <li>Assert <Response 3 GET> (GET resource correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[entity-header].Content-Type = text/turtle</li>
+ </ul>
+ </li>
+ <li> Assert <Response 3 GET> (GET container correct):
+ <ul>
+ <li>[message-body] contains rdf:type ldp:Container</li>
+ </ul>
+ </li>
+ <li>Assert <Response 3 GET> (LDPC updated):
+ <ul>
+ <li>[response-header].ETag != <Response 1
+ GET>.[response-header].ETag</li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-C5">TC-C5. PUT on an LDPC without matching ETags</a></h3>
+ <h4>Related specification</h4>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>4.4.2 [...] LDPR servers MUST respond with status code 412 (Condition
+ Failed) if ETags fail to match if there are no other errors with the
+ request. </li>
+ </ul>
+ <h4>Input<em> </em></h4>
+ <ul>
+ <li><em> <LDPC URI></em>. The URI of an LDPC</li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPC at <LDPC URI></li>
+ <li>The LDPC at <LDPC URI> allows PUT</li>
+ <li>The LDP server allows updating in the LDPC the current representation
+ at <LDPC URI></li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>GET <LDPC URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ <li>PUT <LDPC URI>
+ <ul>
+ <li>[request-header].If-Match = <Response GET
+ 1>.[response-header].ETag + 'M'</li>
+ <li>[message-body] = <Response GET 1>.[message-body]</li>
+ </ul>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 GET></em></li>
+ <li> <em> <Response 2 PUT></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 GET> (GET resource correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[entity-header].Content-Type = text/turtle</li>
+ </ul>
+ </li>
+ <li>Assert <Response 1 GET> (GET container correct):
+ <ul>
+ <li>[message-body] contains rdf:type ldp:Container</li>
+ </ul>
+ </li>
+ <li>Assert <Response 2 PUT> (PUT correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 412</li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-C6">TC-C6. DELETE on an LDPC</a></h3>
+ <h4>Related specification</h4>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>4.5.1 LDPR servers MUST remove the resource identified by the
+ Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on
+ the same Request-URI MUST result in a 404 (Not found) or 410 (Gone)
+ status code.</li>
+ </ul>
+ <h4>Input</h4>
+ <ul>
+ <li> <em><LDPC URI></em>. The URI of an LDPC </li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPC at <LDPC URI></li>
+ <li>The LDPC at <LDPC URI> allows DELETE</li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>DELETE <LDPC URI></li>
+ <li>GET <LDPC URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 DELETE></em></li>
+ <li> <em> <Response 2 GET></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 DELETE> <Response 2 GET> (DELETE
+ correct): </li>
+ <li>
+ <ul>
+ <li><Response 1 DELETE>.[Status-Line].Status-Code = 200 or 204 and
+ <Response 2 GET>.[Status-Line].Status-Code = 404 or 410<strong>
+ </strong></li>
+ <li>or </li>
+ <li><Response 1 DELETE>.[Status-Line].Status-Code = 2xx (except
+ 200 and 204)
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-C7">TC-C7. DELETE on an LDPR in an LDPC</a></h3>
+ <h4>Related specification</h4>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>5.6.1 When a LDPC member resource originally created by the LDPC (for
+ example, one referenced by a membership triple) is deleted, and the LDPC
+ server is aware of the member's deletion (for example, the member is
+ managed by the same server), the LDPC server MUST also remove it from
+ the LDPC by removing the corresponding membership triple. </li>
+ </ul>
+ <h4>Input</h4>
+ <ul>
+ <li><em><LDPC URI></em>. The URI of an LDPC. </li>
+ <li><em><LDPR URI></em>. The URI of an LDPR that is a member of the
+ LDPC. </li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPC at <LDPC URI></li>
+ <li>The LDP server contains an LDPR at <LDPR URI></li>
+ <li>The LDPR is a member of the LDPC</li>
+ <li>The LDPR at <LDPR URI> allows DELETE</li>
+ <li>The LDPR was originally created by the LDPC</li>
+ <li>The LDPC is aware of the member's deletion</li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>DELETE <LDPR URI></li>
+ <li>GET <LDPR URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ <li>GET <LDPC URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 DELETE></em></li>
+ <li> <em> <Response 2 GET></em></li>
+ <li> <em> <Response 3 GET></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 DELETE> <Response 2 GET> (DELETE
+ correct):
+ <ul>
+ <li><Response 1 DELETE>.[Status-Line].Status-Code = 200 or 204
+ and <Response 2 GET>.[Status-Line].Status-Code = 404 or 410<strong>
+ </strong></li>
+ <li>or </li>
+ <li><Response 1 DELETE>.[Status-Line].Status-Code = 2xx (except
+ 200 and 204)</li>
+ </ul>
+ </li>
+ <li>Assert <Response 3 GET> (GET resource correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[entity-header].Content-Type = text/turtle</li>
+ </ul>
+ </li>
+ <li>Assert <Response 3 GET> (GET container correct):
+ <ul>
+ <li>[message-body] contains rdf:type ldp:Container</li>
+ </ul>
+ </li>
+ <li>Assert <Response 3 GET> (member removed from container)
+ <ul>
+ <li>[message-body] not contains the member identified by <LDPR
+ URI></li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-C8">TC-C8. HEAD on an LDPC</a></h3>
+ <h4>Related specification</h4>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>4.6.1 LDPR servers MUST support the HTTP HEAD method.</li>
+ <li>4.6.2 LDPR servers MUST indicate their support for HTTP Methods by
+ responding to a HTTP HEAD request on the LDPR’s URL with the HTTP Method
+ tokens in the HTTP response header “Allow”. </li>
+ </ul>
+ <p><a target="_blank" href="http://tools.ietf.org/html/rfc2616"><em>Hypertext
+ Transfer Protocol -- HTTP/1.1</em></a>:</p>
+ <ul>
+ <li>9.4 The HEAD method is identical to GET except that the server MUST
+ NOT return a message-body in the response.</li>
+ </ul>
+ <h4>Input</h4>
+ <ul>
+ <li> <em><LDPC URI></em>. The URI of an LDPC </li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPC at <LDPC URI></li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>HEAD <LDPC URI></li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 HEAD></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 HEAD> (HEAD correct): </li>
+ <li>
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx<strong> </strong></li>
+ <li>[entity-header].Allow exists</li>
+ <li>[message-body] not exists</li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h3><a id="TC-C9">TC-C9. POST an LDPR on an LDPC</a></h3>
+ <h4>Related specification</h4>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>5.4.1 [...] If the resource was created successfully, LDPC servers
+ MUST respond with status code 201 (Created) and the Location header set
+ to the new resource’s URL. [...] </li>
+ <li>5.4.2 After a successful HTTP POST request to a LDPC, the new resource
+ MUST appear as a member of the LDPC until the new resource is deleted or
+ removed by other methods. [...] </li>
+ <li>5.4.4 For servers that support create, LDPC servers MUST create an
+ LDPR from a RDF representation in the request entity body. [...]</li>
+ <li>5.4.5 LDPC servers MUST accept a request entity body with a request
+ header of Content-Type with value of text/turtle. </li>
+ </ul>
+ <h4>Input </h4>
+ <ul>
+ <li> <em><LDPC URI></em>. The URI of an LDPC</li>
+ <li><em><LDPR representation></em>. The representation of the LDPR
+ to be created</li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li>The LDP server contains an LDPC at <LDPC URI></li>
+ <li>The LDPC at <LDPC URI> allows POST</li>
+ <li>The LDP server does not desire to direct the user agent to retrieve a
+ cacheable resource</li>
+ <li><LDPR representation> is in text/turtle</li>
+ <li><LDPR representation> is a valid representation for a resource
+ to be created in the LDPC</li>
+ <li><LDPR representation> uses null relative URI as the entity in
+ the request body</li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li>POST <LDPC URI>
+ <ul>
+ <li>[entity-header].Content-type = text/turtle</li>
+ <li>[message-body] = <LDPR representation></li>
+ </ul>
+ </li>
+ <li>GET <LDPC URI>
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ <li>GET <Response POST>.[response-header].Location
+ <ul>
+ <li>[request-header].Accept = text/turtle</li>
+ </ul>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li> <em> <Response 1 POST></em></li>
+ <li> <em> <Response 2 GET></em></li>
+ <li> <em> <Response 3 GET></em></li>
+ </ul>
+ <h4>Expected result</h4>
+ <ul>
+ <li>Assert <Response 1 POST> (POST correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 201</li>
+ <li>[response-header].Location exists</li>
+ </ul>
+ </li>
+ <li>Assert <Response 2 GET> (GET resource correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[entity-header].Content-Type = text/turtle</li>
+ </ul>
+ </li>
+ <li>Assert <Response 2 GET> (GET container correct):
+ <ul>
+ <li>[message-body] contains rdf:type ldp:Container</li>
+ </ul>
+ </li>
+ <li>Assert <Response 2 GET> (container has new member):
+ <ul>
+ <li>[message-body] contains a new member identified by <Response 1
+ POST>.[response-header].Location</li>
+ </ul>
+ </li>
+ <li>Assert <Response 3 GET> (GET resource correct):
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[entity-header].Content-Type = text/turtle</li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+ <h2><a id="Feedback">Feedback to recommendation</a></h2>
+ <ul>
+ <li>LDP 1.0. 4.4.1 If HTTP PUT is performed on an existing resource, LDPR
+ servers MUST replace the entire persistent state of the identified
+ resource with the entity representation in the body of the request.
+ <ul>
+ <li>Raúl: Currently there are no restrictions on the representation of
+ resources allowed by a server. Therefore, an LDPR representation
+ submitted by a client may include properties that will be ignored by
+ the server and properties that will not be ignored by the server.
+ Besides, the LDPR representation provided by a server may include
+ properties submitted by the client and properties not managed by the
+ client (e.g., timestamp). Right now it may happen that all the
+ properties in the client representation are ignored and the server
+ representation includes only server managed properties (i.e., the
+ specification does not restrict this).</li>
+ <li><p>Miguel: Requiring the complete replacement of a resource state
+ with the input representation included on the body of the PUT
+ request implies that all the properties exposed for an LDPR can be
+ freely modified by the client. </p>
+ <p>While this can be the case for vanilla LDP servers, which don’t take
+ into account the contents of the resources, it does not hold for
+ domain-dependent LDP servers that expose data for whom specific
+ restrictions apply, i.e., certain properties are not under the
+ control of the client. </p>
+ <p>At the same time, this MUST clause does not align with what is said
+ in the next MAY clause on the same point, which asserts that LDP
+ servers can ignore server managed properties. </p>
+ <p>My proposal would be to rewrite the clause making clear that only
+ the part of the LDPR state that is under the control of the client
+ will be updated with the contents of the representation, and that it
+ is the responsibility of the LDP Server to define which parts of the
+ representation are under its control. </p></li>
+ </ul>
+ </li>
+ <li>LDP 1.0. 4.4.2 [...] LDPR servers MUST respond with status code 412
+ (Condition Failed) if ETags fail to match if there are no other errors
+ with the request.
+ <ul>
+ <li>Miguel: There are other alternatives for using ETags apart from
+ using the If-Match header, i.e., If-None-Match header. The
+ specification should be clear about this, either disallowing its
+ usage, advising against its usage or allowing its usage. </li>
+ </ul>
+ </li>
+ <li>LDP 1.0. 4.5.1 LDPR servers MUST remove the resource identified by the
+ Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on
+ the same Request-URI MUST result in a 404 (Not found) or 410 (Gone)
+ status code.
+ <ul>
+ <li>Raúl: A successful HTTP DELETE request (i.e., 2xx) does not imply
+ that the resource has been deleted, the request may be accepted
+ (i.e., status code 202) but not enacted.</li>
+ <li>Miguel: Does the LDP specification want to allow any other status
+ code for the DELETE operation beyond the HTTP/1.1 recommended 200,
+ 202, and 204? The other status codes do not make sense, and as the
+ HTTP/1.1 specification does not enforce but recommend these three,
+ it might be worthy making this a strong requirement in LDP.</li>
+ <li>Miguel: The second MUST clause implies that URIs will not be
+ reusable. This has strong implications and should be clarified
+ somewhere else in the specification.</li>
+ </ul>
+ </li>
+ <li>LDP 1.0. 4.6.1 LDPR servers MUST support the HTTP HEAD method.
+ <ul>
+ <li>Miguel: The HEAD method has been confused with the OPTIONS one. <p>
+ According to section 9.4 in the HTTP/1.1 specification, the HEAD
+ method “is identical to GET except that the server MUST NOT return a
+ message-body in the response. The metainformation contained in the
+ HTTP headers in response to a HEAD request SHOULD be identical to
+ the information sent in response to a GET request. This method can
+ be used for obtaining metainformation about the entity implied by
+ the request without transferring the entity-body itself. This method
+ is often used for testing hypertext links for validity,
+ accessibility, and recent modification”. </p>
+ <p>
+ In contrast, according to section 9.2 of the same specification, the
+ OPTIONS method “represents a request for information about the
+ communication options available on the request/response chain
+ identified by the Request-URI. This method allows the client to
+ determine the options and/or requirements associated with a
+ resource, or the capabilities of a server, without implying a
+ resource action or initiating a resource retrieval”. </p></li>
+ <li>Miguel: Given the point before, point 4.6.2 should be also updated
+ accordingly.</li>
+ </ul>
+ </li>
+ <li>The current specification does not impose any absolute (MUST)
+ restriction on LDPR representations. Therefore, "almost" any server
+ returning text/turtle and satisfying some other protocol restrictions
+ would be an LDP-conformant server. The proposal is to require, similarly
+ as for LDPCs, that LDPR representations are typed (i.e., "The
+ representation of a LDPR MUST have rdf:type of ldp:Resource, but it MAY
+ have additional rdf:types."). One advantage of having this restriction
+ is that a client can discover whether the resource is in an LDP server
+ or not; if not, no one ensures the client that other resources appearing
+ in the representation can be dereferenced and so on.</li>
+ </ul>
+ <h3>MUSTs currently not tested</h3>
+ <p><em><em><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data
+ Platform 1.0</a></em>:</em></p>
+ <ul>
+ <li>4.4.1 If HTTP PUT is performed on an existing resource, LDPR servers
+ MUST replace the entire persistent state of the identified resource with
+ the entity representation in the body of the request. </li>
+ <li>5.4.7 In RDF representations, LDPC servers MUST interpret the null
+ relative URI for the subject of triples in the LDPR representation in
+ the request entity body as referring to the entity in the request body.
+ [...]</li>
+ </ul>
+ <h2><a id="EditorNotes">Editor TODOs and notes</a></h2>
+ <ul>
+ <li>Add tests for MUSTs related to containers when the issue about
+ aggregation and composition is solved</li>
+ <li>Include RDFa annotations</li>
+ <li>Include a section describing the RDF Schema for test suite and results</li>
+ <li>Include a section describing how to describe results</li>
+ <li>Format document as a specification</li>
+ </ul>
+ </body>
+</html>