--- a/Test Cases/LDP Test Cases.html Tue May 21 15:46:16 2013 -0400
+++ b/Test Cases/LDP Test Cases.html Mon Jun 03 16:05:36 2013 +0200
@@ -1,22 +1,22 @@
-<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.1.dtd">
<html
xmlns="http://www.w3.org/1999/xhtml"
prefix="td: http://www.w3.org/2006/03/test-description# tn: http://ldp.example.org/NewTestDefinitions# ht: http://www.w3.org/2011/http#">
<head>
<meta content="text/html; charset=utf-8" http-equiv="content-type" />
<!-- rgarcia: Had to uncomment it so it can read the local image
<base href="http://www.w3.org/TR/ldp/TestCases">-->
<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 src="http://www.w3.org/Icons/w3c_home"
alt="W3C"
height="48"
width="72" /></a>
</p>
<h1>Linked Data Platform 1.0 Test Cases</h1>
<h2>Table of Contents</h2>
<p><a href="#Introduction"><strong>Introduction</strong></a></p>
<p><a href="#DesignIssues"><strong>Design issues</strong></a></p>
<ul>
<li><a href="#GenericVsDomain">Generic vs domain-specific servers</a></li>
<li><a href="#ProtocolVsData">Protocol evaluation vs data evaluation</a></li>
<li><a href="#Coverage">Test suite coverage</a></li>
<li><a href="#ResultVsAssertion">Separation of results and assertions</a></li>
<li><a href="#Traceability">Traceability of test cases</a></li>
</ul>
<p><a href="#TestingProcess"><strong>Testing process</strong></a></p>
<p><a href="#DescribingArtifacts"><strong>Describing testing artifacts in RDF</strong></a></p>
<ul>
<li><a href="#Namespaces">Namespaces used</a></li>
<li><a href="#TestSuiteDescription">Test suite description</a></li>
<li><a href="#TestCaseDescription">Test case description</a></li>
<li><a href="#ExecutionReportDescription">Execution report description</a></li>
<li><a href="#AssertionDescription">Test case assertion description</a></li>
</ul>
<p><a href="#Tests-LDPRs"><strong>Tests for LDPRs</strong></a>:</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 LDPCs</strong></a>:</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><a id="Introduction">Introduction</a></h2>
<p>This document describes...</p>
<h2><a id="DesignIssues">Design issues </a></h2>
<h3><a id="GenericVsDomain">Generic vs domain-specific servers</a></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><a id="ProtocolVsData">Protocol evaluation vs data evaluation</a></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><a id="Coverage">Test suite coverage</a></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><a id="ResultVsAssertion">Separation of results and assertions</a></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>
<h3><a id="Traceability">Traceability of test cases</a></h3>
<p>Any test case and its produced results and assertions should be related to those documents that are relevant for
it (e.g., specifications, uses cases, etc.).</p>
<h2><a id="TestingProcess">Testing process</a></h2>
<p>The LDP Test Cases are defined in this same page, which is annotated using RDFa so that it can be consumed both by
persons and machines. The testing process is composed of two steps, depicted in the figure below.</p>
<ol>
<li>The person or agent in charge of executing the test cases in a concrete LDP server will take the test case
definitions and run every test case on the LDP server. It is recommended (but not compulsory) that test
execution is automated. The execution of test cases must produce a test execution report for the LDP server, in
RDF format, that contains for every test case the concrete inputs used during its execution and the produced
outputs. The test execution report must be available in the Web.</li>
<li>A validator software will take all the LDP server execution reports and, according to the test inputs and
outputs in them, will assert whether test cases are passed or not. The validator will generate an implementation
report that includes the results of all the LDP servers and is annotated using RDFa.</li>
</ol>
<p>
<object data="TestingProcess.svg" type="image/svg+xml">Your browser does not support SVG.</object>
</p>
<h2><a id="DescribingArtifacts">Describing testing artifacts in RDF</a></h2>
<h3><a id="Namespaces">Namespaces used</a></h3>
<p>The following vocabularies are reused for describing the testing artifacts: DOAP (<em>doap</em>), Dublin Core (<em>dc</em>),
- FOAF (<em>foa</em><em>f</em>), HTTP Vocabulary in RDF (<em>ht</em>), and W3C Test Metadata (<em>td</em>).</p>
<p>All the new required entities that are not covered by those vocabularies have been defined under a new namespace
(<em>tn</em>). Besides, the LDP test cases have been defined under their own namespace (<em>ldptc</em>).</p>
<p>Next we present the definition of these namespaces and of all the namespaces used in the examples.</p>
<pre>cnt: <http://www.w3.org/2011/content#>
dc: <http://purl.org/dc/terms/>
doap: <http://usefulinc.com/ns/doap#>
earl: <http://www.w3.org/ns/earl#>
foaf: <http://xmlns.com/foaf/0.1/>
ht: <http://www.w3.org/2011/http#>
httph: <http://www.w3.org/2011/http-headers#>
ldptc: <http://www.w3.org/TR/ldp/TestCases#>
td: <http://www.w3.org/2006/03/test-description#>
tn: <http://ldp.example.org/NewTestDefinitions#></pre>
<h3><a id="TestSuiteDescription">Test suite description</a></h3>
<p><em>To be comnpleted</em></p>
<h3><a id="TestCaseDescription">Test case description</a></h3>
<p>A <strong>test case</strong> is defined as an instance of the <em>td:TestCase</em> class and it can be further
described using the following properties:</p>
<ul>
<li><em>rdfs:label</em>. The human-readable label of the test.</li>
<li><em>dc:title</em>. The name of the test.</li>
<li><em>dc:description</em>. The description of the test.</li>
<li><em>dc:contributor</em>. The person (<em>foaf:Person</em>) contributing the test.</li>
<li><em>td:reviewStatus</em>. The status of the test; possible status are: <em>td:unreviewed</em>, <em>td:approved</em>
or <em>td:rejected</em>.</li>
<li><em>rdfs:seeAlso</em>. A link to the specification it refers to.</li>
<li><em>td:specificationReference</em>. An excerpt (<em>tn:E</em><em>xcerpt</em>) of the specification that is
relevant to the test.</li>
<li><em>td:input</em>. An input (<em>tn:TestInput</em>) used in the test.</li>
<li><em>td:precondition</em>. A precondition that must be satisfied before running the test.</li>
<li><em>tn:output</em>. An output (<em>tn:TestOutput</em>) to be produced by the test.</li>
<li><em>tn:testProcess</em>. The list of steps (<em>tn:Step</em>) to be performed during the test.</li>
<li><em>tn:testAssertion</em>. An assertion (<em>tn:TestAssertion</em>) to be performed over the test output.</li>
</ul>
<p>A <strong>test input</strong> is defined as an instance of the <em>td:TestInput </em>class and it can be
further described using the following properties:</p>
<ul>
<li><em>dc:title</em>: The name of the test input.</li>
<li><em>dc:description</em>. The description of the test input.</li>
</ul>
<div class="example">
<div class="example-title">A <strong>test output</strong> is defined as an instance of the <em>td:TestOutput</em>
class and it can be further described using the following properties:
<ul>
<li><em>dc:title</em>: The name of the test output.</li>
<li><em>dc:description</em>. The description of the test output.</li>
<li><em>tn:fromStep</em>. The step in the process in which the output is produced.</li>
</ul>
<p>In the LDP test cases, test outputs are expected to be HTTP responses (<em>ht:Response</em>).</p>
<p>A <strong>step</strong> in the test process is defined as an instance of the <em>td:Step</em> class and it
can be further described using the following properties:</p>
<ul>
<li><em>dc:description</em>. The description of the step.</li>
<li><em>tn:usesInput</em>. A test input used in the step.</li>
</ul>
<p>In the LDP test cases, steps are expected to be HTTP requests (<em>ht:Request</em>).</p>
<p>A <strong>test assertion</strong> is defined as an instance of the <em>td:TestAssertion</em> class and it
can be further described using the following properties:</p>
<ul>
<li><em>dc:title</em>: The name of the test assertion.</li>
<li><em>dc:description</em>. The description of the test assertion.</li>
<li><em>tn:outputAsserted</em>. An output under assertion.</li>
</ul>
<p>The following example contains the description of one of the LDP test cases.</p>
<span>Example 1</span></div>
<pre class="example" id="test-case-example">:TCR1 a td:TestCase;
rdfs:label "TC-R1";
dc:title "GET on an LDPR";
dc:description "Tests making a GET request on an existing LDPR";
dc:contributor :RaulGarciaCastro;
td:reviewStatus td:unreviewed;
rdfs:seeAlso <http://www.w3.org/TR/ldp/>;
td:specificationReference [
a tn:Excerpt;
rdfs:seeAlso <http://www.w3.org/TR/ldp/>;
tn:includesText "4.1.12 LDPR server responses MUST use entity tags (either weak or strong ones) as response ETag header values.".
],
[
a tn:Excerpt;
rdfs:seeAlso <http://www.w3.org/TR/ldp/>;
tn:includesText "4.2.1 LDPR servers MUST support the HTTP GET Method for LDPRs.".
],
[
a tn:Excerpt;
rdfs:seeAlso <http://www.w3.org/TR/ldp/>;
tn:includesText "4.2.2 LDPR servers MUST provide a text/turtle representation of the requested LDPR.".
];
td:input :TCR1-I1-LDPR-URI;
td:precondition "The LDP server contains an LDPR at <LDPR URI>";
tn:output :TCR1-RP1-Response-1-GET;
tn:testProcess (:TCR1-RQ1-GET-LDPR-URI);
tn:testAssertion :TCR1-A1-Response-1-GET.
:RaulGarciaCastro a foaf:Person;
rdfs:label "Raúl García-Castro";
owl:sameAs <http://delicias.dia.fi.upm.es/~rgarcia/#me>.
:TCR1-I1-LDPR-URI a tn:TestInput;
dc:title "<LDPR URI>";
dc:description "The URI of an LDPR".
:TCR1-RP1-Response-1-GET a tn:TestOutput;
a ht:Response;
tn:fromStep :TCR1-RQ1-GET-LDPR-URI;
dc:title "<Response 1 GET>";
dc:description "The response of the GET request in step 1".
:TCR1-RQ1-GET-LDPR-URI a tn:Step;
a ht:Request;
dc:description """GET <LDPR URI>
[request-header].Accept = text/turtle""";
tn:usesInput :TCR1-I1-LDPR-URI.
:TCR1-A1-Response-1-GET a tn:TestAssertion;
tn:outputAsserted :TCR1-O1-Response-1-GET;
dc:title "GET correct";
dc:description """[Status-Line].Status-Code = 2xx
[response-header].ETag exists
[entity-header].Content-Type = text/turtle""".
</pre></div>
<h3><a id="ExecutionReportDescription">Execution report description</a></h3>
<p>A <strong>test execution</strong> is defined as an instance of the <em>tn:TestExecution</em> class and it can
be further described using the following properties:</p>
<ul>
<li><em>tn:testExecuted</em>. The test case (<em>td:TestCase</em>) used in the execution.</li>
<li><em>tn:subjectTested</em>. The subject (<em>doap:Project</em>) tested.</li>
<li><em>dc:date</em>. The date when the test was executed.</li>
<li><em>tn:inputUsed</em>. The input value (<em>tn:TestInputValue</em>) used in the execution.</li>
<li><em>tn:outputProduced</em>. The output value (<em>tn:TestOutputValue</em>) produced in the execution.</li>
</ul>
<p>A <strong>test input value</strong> is defined as an instance of the <em>tn:TestInputValue</em> class and it
can be further described using the following properties:</p>
<ul>
<li><em>tn:relatedInput</em>. The input in the test definition (<em>tn:TestInput</em>) for which the value is
defined.</li>
<li><em>tn:inputValue</em>. The concrete input defined for the execution.</li>
</ul>
<p>A <strong>test output value</strong> is defined as an instance of the <em>tn:TestOutputValue</em> class and it
can be further described using the following properties:</p>
<ul>
<li><em>tn:relatedOutput</em>. The output in the test definition (<em>tn:TestOutput</em>) for which the value is
defined.</li>
<li><em>tn:outputValue</em>. The concrete output defined for the execution.</li>
</ul>
<p>In the LDP test cases, test output values are expected to be HTTP responses (<em>ht:Response</em>).</p>
<p>The following example contains the description of one test execution.</p>
<p><span>Example 2</span> </p>
<pre class="example" id="execution-report-example">:TCR1-Execution a tn:TestExecution;
tn:testExecuted ldptc:TCR1;
tn:subjectTested :SomeServer;
dc:date "2013-03-30T09:30:10";
tn:inputUsed [
a tn:TestInputValue ;
tn:relatedInput :TCR1-I1-LDPR-URI ;
tn:inputValue <http://www.example.org/MyResource> .
];
tn:outputProduced [
a tn:TestOutputValue ;
tn:relatedOutput :TCR1-RP1-Response-1-GET ;
tn:outputValue :TCR1-Exec-Response-1-GET .
].
:SomeServer a doap:Project;
doap:name "Sample server".
:TCR1-Exec-Response-1-GET a ht:Response;
ht:httpVersion "1.1";
dc:date "2013-03-30T09:30:10";
ht:sc <http://www.w3.org/2011/http-statusCodes#OK>;
ht:statusCodeValue "200";
ht:reasonPhrase "OK";
ht:headers (
[
a ht:ResponseHeader;
ht:hdrName httph:etag;
ht:fieldName "ETag";
ht:fieldValue "hd73hck43".
]
[
a ht:EntityHeader;
ht:hdrName httph:content-type;
ht:fieldName "Content-Type";
ht:fieldValue "text/turtle; charset=utf-8".
]
);
ht:body [
a cnt:ContentAsText ;
cnt:chars """
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix dc: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
<http://example.org/MyResource>
a ldp:Resource;
dc:title "My LDP resource".
""";
cnt:characterEncoding "UTF-8".
].
</pre>
<h3><a id="AssertionDescription">Test case assertion description</a></h3>
<p>An <strong>assertion</strong> is defined as an instance of the <em>earl:Assertion</em> class and it can be
further described using the following properties:</p>
<ul>
<li><em>earl:subject</em>.The subject (<em>doap:Project</em>) asserted.</li>
<li><em>earl:test</em>. The test case (<em>td:TestCase</em>) to which the assertion refers to.</li>
<li><em>tn:fromTestExecution</em>. The test execution (<em>td:TestExecution</em>) used in the assertion.</li>
<li><em>dc:date</em>. The date when the assertion was performed.</li>
<li><em>earl:assertedBy</em>. The validator (<em>doap:Project</em>) that makes the assertion.</li>
<li><em><em>earl:mode</em>.</em> The execution mode of the validator. In this case it will always be <em>earl:automatic</em>.
<em><em></em></em></li>
<li><em><em></em>earl:result</em>. The outcome value (<em>earl:OutcomeValue</em>) of the assertion.</li>
</ul>
<p>The following example contains the description of one test assertion.</p>
<p><span>Example 3</span> </p>
<pre class="example" id="test-assertion-example">:TCR1-Assertion-SomeServer a earl:Assertion;
earl:subject sr:SomeServer;
earl:test ldptc:TCR1;
tn:fromTestExecution sr:TCR1-Execution;
dc:date "2013-03-30T09:30:10";
earl:assertedBy :Validator;
earl:mode: earl:automatic;
earl:result [
a earl:OutcomeValue ;
earl:outcome earl:passed .
].
:Validator a doap:Project;
doap:name "Some validator".</pre>
<h2><a id="Tests-LDPRs"></a>Tests for LDPRs</h2>
<p>These tests involve only LDPRs.</p>
<div resource="#TCR1" typeof="td:TestCase">
<h3><a id="TC-R1"><span property="rdfs:label">TC-R1</span>. <span property="dc:title">GET on an LDPR</span></a></h3>
<p property="dc:description">Tests making a GET request on an existing LDPR.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl
+<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.1.dtd">
<html
xmlns="http://www.w3.org/1999/xhtml"
prefix="td: http://www.w3.org/2006/03/test-description# tn: http://ldp.example.org/NewTestDefinitions# ht: http://www.w3.org/2011/http#">
<head>
<meta content="text/html; charset=utf-8" http-equiv="content-type" />
<!-- rgarcia: Had to uncomment it so it can read the local image
<base href="http://www.w3.org/TR/ldp/TestCases">-->
<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 src="http://www.w3.org/Icons/w3c_home"
alt="W3C"
height="48"
width="72" /></a>
</p>
<h1>Linked Data Platform 1.0 Test Cases</h1>
<h2>Table of Contents</h2>
<p><a href="#Introduction"><strong>Introduction</strong></a></p>
<p><a href="#DesignIssues"><strong>Design issues</strong></a></p>
<ul>
<li><a href="#GenericVsDomain">Generic vs domain-specific servers</a></li>
<li><a href="#ProtocolVsData">Protocol evaluation vs data evaluation</a></li>
<li><a href="#Coverage">Test suite coverage</a></li>
<li><a href="#ResultVsAssertion">Separation of results and assertions</a></li>
<li><a href="#Traceability">Traceability of test cases</a></li>
</ul>
<p><a href="#TestingProcess"><strong>Testing process</strong></a></p>
<p><a href="#DescribingArtifacts"><strong>Describing testing artifacts in RDF</strong></a></p>
<ul>
<li><a href="#Namespaces">Namespaces used</a></li>
<li><a href="#TestSuiteDescription">Test suite description</a></li>
<li><a href="#TestCaseDescription">Test case description</a></li>
<li><a href="#ExecutionReportDescription">Execution report description</a></li>
<li><a href="#AssertionDescription">Test case assertion description</a></li>
</ul>
<p><a href="#Tests-LDPRs"><strong>Tests for LDPRs</strong></a>:</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 LDPCs</strong></a>:</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="#ChangeHistory">Change history</a></p>
<p><a href="#EditorNotes">Editor TODOs and notes</a></p>
<hr/>
<h2><a id="Introduction">Introduction</a></h2>
<p>This document describes...</p>
<h2><a id="DesignIssues">Design issues </a></h2>
<h3><a id="GenericVsDomain">Generic vs domain-specific servers</a></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 specific input data in the test suite. It is up to the
evaluator to define specific 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><a id="ProtocolVsData">Protocol evaluation vs data evaluation</a></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 certain 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><a id="Coverage">Test suite coverage</a></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, <dfn>LDP Core</dfn> 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><a id="ResultVsAssertion">Separation of results and assertions</a></h3>
<p>Instead of defining expected results for tests, which will be dependent on specific implementations, we have
defined the assertions to be made over test results. In order to successfully pass a test, all of 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>
<h3><a id="Traceability">Traceability of test cases</a></h3>
<p>Any test case and its produced results and assertions should be related to those documents that are relevant for
it (e.g., specifications, uses cases, etc.).</p>
<h2><a id="TestingProcess">Testing process</a></h2>
<p>The LDP Test Cases are defined in this same page, which is annotated using RDFa so that it can be consumed both by
persons and machines. The testing process is composed of two steps, depicted in the figure below.</p>
<ol>
<li>The person or agent in charge of executing the test cases in a specific LDP server will take the test case definitions and run every test case on the LDP server. It is recommended (but not required) that test execution is automated. The execution of test cases must produce a test execution report for the LDP server, in RDF format, that contains for every test case: the specific inputs used during its execution, the produced outputs, and the assertion of whether the test case is passed. The test execution report must be available in the Web.</li>
<li>A report generator software will take all the LDP server execution reports and will generate an implementation report that includes the results of all the LDP servers.</li>
</ol>
<p>
<object data="TestingProcess.svg" type="image/svg+xml">Your browser does not support SVG.</object>
</p>
<h2><a id="DescribingArtifacts">Describing testing artifacts in RDF</a></h2>
<h3><a id="Namespaces">Namespaces used</a></h3>
<p>The following vocabularies are reused for describing the testing artifacts: DOAP (<code>doap</code>), Dublin Core (<code>dc</code>),
+ FOAF (<code>foaf</code>), HTTP Vocabulary in RDF (<code>ht</code>), and W3C Test Metadata (<code>td</code>).</p>
<p>All the new required entities that are not covered by those vocabularies have been defined under a new namespace
(<code>tn</code>). Besides, the LDP test cases have been defined under their own namespace (<code>ldptc</code>).</p>
<p>Next we present the definition of these namespaces and of all the namespaces used in the examples.</p>
<pre>cnt: <http://www.w3.org/2011/content#>
dc: <http://purl.org/dc/terms/>
doap: <http://usefulinc.com/ns/doap#>
earl: <http://www.w3.org/ns/earl#>
foaf: <http://xmlns.com/foaf/0.1/>
ht: <http://www.w3.org/2011/http#>
httph: <http://www.w3.org/2011/http-headers#>
ldptc: <http://www.w3.org/TR/ldp/TestCases#>
td: <http://www.w3.org/2006/03/test-description#>
tn: <http://ldp.example.org/NewTestDefinitions#></pre>
<h3><a id="TestSuiteDescription">Test suite description</a></h3>
<p><em>To be completed</em></p>
<h3><a id="TestCaseDescription">Test case description</a></h3>
<p>A <dfn id="dfn-test-case" title="test case">test case</dfn> is defined as an instance of the <code>td:TestCase</code> class and it can be further
described using the following properties:</p>
<ul>
<li><code>rdfs:label</code>. The human-readable label of the test.</li>
<li><code>dc:title</code>. The name of the test.</li>
<li><code>dc:description</code>. The description of the test.</li>
<li><code>dc:contributor</code>. The person (<code>foaf:Person</code>) contributing the test.</li>
<li><code>td:reviewStatus</code>. The status of the test; possible status are: <code>td:unreviewed</code>, <code>td:approved</code>
or <code>td:rejected</code>.</li>
<li><code>rdfs:seeAlso</code>. A link to the specification it refers to.</li>
<li><code>td:specificationReference</code>. An <a href="#dfn-excerpt">excerpt</a> (<code>tn:Excerpt</code>) of the specification that is
relevant to the test.</li>
<li><code>td:input</code>. An <a href="#dfn-test-input">input</a> (<code>tn:TestInput</code>) used in the test.</li>
<li><code>td:precondition</code>. A precondition that must be satisfied before running the test.</li>
<li><code>tn:output</code>. An <a href="#dfn-test-output">output</a> (<code>tn:TestOutput</code>) to be produced by the test.</li>
<li><code>tn:testProcess</code>. The list of <a href="#dfn-step">steps</a> (<code>tn:Step</code>) to be performed during the test.</li>
<li><code>tn:testAssertion</code>. An <a href="#dfn-test-assertion">assertion</a> (<code>tn:TestAssertion</code>) to be performed over the test output.</li>
</ul>
<p>An <dfn id="dfn-excerpt" title="excerpt">excerpt</dfn> is defined as an instance of the <code>tn:Excerpt </code>class and it can be
further described using the following properties:</p>
<ul>
<li><code>rdfs:seeAlso</code>: The document where the excerpt is included.</li>
<li><code>tn:includesText</code>. The excerpt from the document.</li>
</ul>
<p>A <dfn id="dfn-test-input" title="test input">test input</dfn> is defined as an instance of the <code>td:TestInput </code>class and it can be
further described using the following properties:</p>
<ul>
<li><code>dc:title</code>: The name of the test input.</li>
<li><code>dc:description</code>. The description of the test input.</li>
</ul>
<p>A <dfn id="dfn-test-output" title="test output">test output</dfn> is defined as an instance of the <code>td:TestOutput</code>
class and it can be further described using the following properties:</p>
<ul>
<li><code>dc:title</code>: The name of the test output.</li>
<li><code>dc:description</code>. The description of the test output.</li>
<li><code>tn:fromStep</code>. The <a href="#dfn-step">step</a> in the process in which the output is produced.</li>
</ul>
<p>In the LDP test cases, test outputs are expected to be HTTP responses (<code>ht:Response</code>).</p>
<p>A <dfn id="dfn-step" title="test input">step</dfn> in the test process is defined as an instance of the <code>td:Step</code> class and it
can be further described using the following properties:</p>
<ul>
<li><code>dc:description</code>. The description of the step.</li>
<li><code>tn:usesInput</code>. A <a href="#dfn-test-input">test input</a> used in the step.</li>
</ul>
<p>In the LDP test cases, steps are expected to be HTTP requests (<code>ht:Request</code>).</p>
<p>A <dfn id="dfn-test-assertion" title="test assertion">test assertion</dfn> is defined as an instance of the <code>td:TestAssertion</code> class and it
can be further described using the following properties:</p>
<ul>
<li><code>dc:title</code>: The name of the test assertion.</li>
<li><code>dc:description</code>. The description of the test assertion.</li>
<li><code>tn:outputAsserted</code>. An <a href="#dfn-test-output">output</a> under assertion.</li>
</ul>
<p>The following example contains the description of one of the LDP test cases.</p>
<div class="example"><div class="example-title"><span>Example 1</span></div>
<pre class="example" id="test-case-example">:TCR1 a td:TestCase;
rdfs:label "TC-R1";
dc:title "GET on an LDPR";
dc:description "Tests making a GET request on an existing LDPR";
dc:contributor :RaulGarciaCastro;
td:reviewStatus td:unreviewed;
rdfs:seeAlso <http://www.w3.org/TR/ldp/>;
td:specificationReference [
a tn:Excerpt;
rdfs:seeAlso <http://www.w3.org/TR/ldp/>;
tn:includesText "4.1.12 LDPR server responses MUST use entity tags (either weak or strong ones) as response ETag header values.".
],
[
a tn:Excerpt;
rdfs:seeAlso <http://www.w3.org/TR/ldp/>;
tn:includesText "4.2.1 LDPR servers MUST support the HTTP GET Method for LDPRs.".
],
[
a tn:Excerpt;
rdfs:seeAlso <http://www.w3.org/TR/ldp/>;
tn:includesText "4.2.2 LDPR servers MUST provide a text/turtle representation of the requested LDPR.".
];
td:input :TCR1-I1-LDPR-URI;
td:precondition "The LDP server contains an LDPR at <LDPR URI>";
tn:output :TCR1-RP1-Response-1-GET;
tn:testProcess (:TCR1-RQ1-GET-LDPR-URI);
tn:testAssertion :TCR1-A1-Response-1-GET.
:RaulGarciaCastro a foaf:Person;
rdfs:label "Raúl García-Castro";
owl:sameAs <http://delicias.dia.fi.upm.es/~rgarcia/#me>.
:TCR1-I1-LDPR-URI a tn:TestInput;
dc:title "<LDPR URI>";
dc:description "The URI of an LDPR".
:TCR1-RP1-Response-1-GET a tn:TestOutput;
a ht:Response;
tn:fromStep :TCR1-RQ1-GET-LDPR-URI;
dc:title "<Response 1 GET>";
dc:description "The response of the GET request in step 1".
:TCR1-RQ1-GET-LDPR-URI a tn:Step;
a ht:Request;
dc:description """GET <LDPR URI>
[request-header].Accept = text/turtle""";
tn:usesInput :TCR1-I1-LDPR-URI.
:TCR1-A1-Response-1-GET a tn:TestAssertion;
tn:outputAsserted :TCR1-O1-Response-1-GET;
dc:title "GET correct";
dc:description """[Status-Line].Status-Code = 2xx
[response-header].ETag exists
[entity-header].Content-Type = text/turtle""".
</pre></div>
<h3><a id="ExecutionReportDescription">Execution report description</a></h3>
<p>A <dfn id="dfn-test-execution" title="test execution">test execution</dfn> is defined as an instance of the <code>tn:TestExecution</code> class and it can
be further described using the following properties:</p>
<ul>
<li><code>tn:testExecuted</code>. The <a href="#dfn-test-case">test case</a> (<code>td:TestCase</code>) used in the execution.</li>
<li><code>tn:subjectTested</code>. The subject (<code>doap:Project</code>) tested.</li>
<li><code>dc:date</code>. The date when the test was executed.</li>
<li><code>tn:inputUsed</code>. The <a href="#dfn-test-input-value">input value</a> (<code>tn:TestInputValue</code>) used in the execution.</li>
<li><code>tn:outputProduced</code>. The <a href="#dfn-test-output-value">output value</a> (<code>tn:TestOutputValue</code>) produced in the execution.</li>
</ul>
<p>A <dfn id="dfn-test-input-value" title="test input value">test input value</dfn> is defined as an instance of the <code>tn:TestInputValue</code> class and it
can be further described using the following properties:</p>
<ul>
<li><code>tn:relatedInput</code>. The <a href="#dfn-test-input">input</a> in the test definition (<code>tn:TestInput</code>) for which the value is
defined.</li>
<li><code>tn:inputValue</code>. The specific input defined for the execution.</li>
</ul>
<p>A <dfn id="dfn-test-output-value" title="test output value">test output value</dfn> is defined as an instance of the <code>tn:TestOutputValue</code> class and it
can be further described using the following properties:</p>
<ul>
<li><code>tn:relatedOutput</code>. The <a href="#dfn-test-output">output</a> in the test definition (<code>tn:TestOutput</code>) for which the value is
defined.</li>
<li><code>tn:outputValue</code>. The specific output defined for the execution.</li>
</ul>
<p>In the LDP test cases, test output values are expected to be HTTP responses (<code>ht:Response</code>).</p>
<p>The following example contains the description of one test execution.</p>
<div class="example"><div class="example-title"><span>Example 2</span></div>
<pre class="example" id="execution-report-example">:TCR1-Execution a tn:TestExecution;
tn:testExecuted ldptc:TCR1;
tn:subjectTested :SomeServer;
dc:date "2013-03-30T09:30:10";
tn:inputUsed [
a tn:TestInputValue ;
tn:relatedInput :TCR1-I1-LDPR-URI ;
tn:inputValue <http://www.example.org/MyResource> .
];
tn:outputProduced [
a tn:TestOutputValue ;
tn:relatedOutput :TCR1-RP1-Response-1-GET ;
tn:outputValue :TCR1-Exec-Response-1-GET .
].
:SomeServer a doap:Project;
doap:name "Sample server".
:TCR1-Exec-Response-1-GET a ht:Response;
ht:httpVersion "1.1";
dc:date "2013-03-30T09:30:10";
ht:sc <http://www.w3.org/2011/http-statusCodes#OK>;
ht:statusCodeValue "200";
ht:reasonPhrase "OK";
ht:headers (
[
a ht:ResponseHeader;
ht:hdrName httph:etag;
ht:fieldName "ETag";
ht:fieldValue "hd73hck43".
]
[
a ht:EntityHeader;
ht:hdrName httph:content-type;
ht:fieldName "Content-Type";
ht:fieldValue "text/turtle; charset=utf-8".
]
);
ht:body [
a cnt:ContentAsText ;
cnt:chars """
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix dc: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
<http://example.org/MyResource>
a ldp:Resource;
dc:title "My LDP resource".
""";
cnt:characterEncoding "UTF-8".
].
</pre></div>
<h3><a id="AssertionDescription">Test case assertion description</a></h3>
<p>An <dfn id="dfn-assertion" title="assertion">assertion</dfn> is defined as an instance of the <code>earl:Assertion</code> class and it can be
further described using the following properties:</p>
<ul>
<li><code>earl:subject</code>.The subject (<code>doap:Project</code>) asserted.</li>
<li><code>earl:test</code>. The <a href="#dfn-test-case">test case</a> (<code>td:TestCase</code>) to which the assertion refers to.</li>
<li><code>tn:fromTestExecution</code>. The <a href="#dfn-test-execution">test execution</a> (<code>td:TestExecution</code>) used in the assertion.</li>
<li><code>dc:date</code>. The date when the assertion was performed.</li>
<li><code>earl:assertedBy</code>. The validator (<code>doap:Project</code>) that makes the assertion.</li>
<li><code><code>earl:mode</code>.</code> The execution mode of the validator. In this case it will always be <code>earl:automatic</code>.</li>
<li><code>earl:result</code>. The outcome value (<code>earl:OutcomeValue</code>) of the assertion.</li>
</ul>
<p>The following example contains the description of one test assertion.</p>
<div class="example"><div class="example-title"><span>Example 3</span></div>
<pre class="example" id="test-assertion-example">:TCR1-Assertion-SomeServer a earl:Assertion;
earl:subject sr:SomeServer;
earl:test ldptc:TCR1;
tn:fromTestExecution sr:TCR1-Execution;
dc:date "2013-03-30T09:30:10";
earl:assertedBy :Validator;
earl:mode: earl:automatic;
earl:result [
a earl:OutcomeValue ;
earl:outcome earl:passed .
].
:Validator a doap:Project;
doap:name "Some validator".</pre></div>
<h2><a id="Tests-LDPRs"></a>Tests for LDPRs</h2>
<p>These tests involve only LDPRs.</p>
<div resource="#TCR1" typeof="td:TestCase">
<h3><a id="TC-R1"><span property="rdfs:label">TC-R1</span>. <span property="dc:title">GET on an LDPR</span></a></h3>
<p property="dc:description">Tests making a GET request on an existing LDPR.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl
García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a>:</em></p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.1.12 LDPR server responses MUST use entity tags (either weak or strong
ones) as response ETag header values.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.1 LDPR servers MUST support the HTTP GET Method for LDPRs.</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.2 LDPR servers MUST provide a text/turtle representation of the
requested LDPR.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCR1-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR
URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR1-RQ1-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description"> GET <LDPR URI>
<ul>
<li>[request-header].Accept = text/turtle</li>
</ul>
</div>
<span property="tn:usesInput" resource="#TCR1-I1-LDPR-URI"> </span></li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR1-RP1-Response-1-GET" typeof="tn:TestOutput ht:Response"> <em property="dc:title"><Response
1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span> <span property="tn:fromStep"
resource="#TCR1-RQ1-GET-LDPR-URI">
</span></li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR1-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted"
resource="TCR1-O1-Response-1-GET">Assert
<Response 1 GET> (<span property="dc:title">GET correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[entity-header].Content-Type = text/turtle</li>
</ul>
</div>
</div></li>
</ul>
</div>
<hr/>
<div resource="#TCR2" typeof="td:TestCase">
<h3><a id="TC-R2">TC-R2. GET on an LDPR without content type</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl
García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
- </p>
<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>Assertions</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>
</ul>
</div>
<hr/>
<div resource="#TCR3" typeof="td:TestCase">
<h3><a id="TC-R3">TC-R3. GET on a non-existing LDPR</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
- </p>
<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>Assertions</h4>
<ul>
<li>Assert <Response 1 GET> (GET incorrect):
<ul>
<li>[Status-Line].Status-Code = 404 or 410</li>
</ul>
</li>
</ul>
</div>
<hr/>
<div resource="#TCR4" typeof="td:TestCase">
<h3><a id="TC-R4">TC-R4. PUT on an LDPR</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
+ </p>
<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.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>Assertions</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>
</ul>
</div>
<hr/>
<div resource="#TCR3" typeof="td:TestCase">
<h3><a id="TC-R3">TC-R3. GET on a non-existing LDPR</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
+ </p>
<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.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>Assertions</h4>
<ul>
<li>Assert <Response 1 GET> (GET incorrect):
<ul>
<li>[Status-Line].Status-Code = 404 or 410</li>
</ul>
</li>
</ul>
</div>
<hr/>
<div resource="#TCR4" typeof="td:TestCase">
<h3><a id="TC-R4">TC-R4. PUT on an LDPR</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
</p>
<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>Assertions</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>
</div>
<hr/>
<div resource="#TCR5" typeof="td:TestCase">
<h3><a id="TC-R5">TC-R5. PUT on an LDPR without matching ETags</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
- </p>
<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>Assertions</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>
</div>
<hr/>
<div resource="#TCR6" typeof="td:TestCase">
<h3><a id="TC-R6">TC-R6. DELETE on an LDPR</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
- </p>
<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>Assertions</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>
</ul>
</div>
<hr/>
<div resource="#TCR7" typeof="td:TestCase">
<h3><a id="TC-R7">TC-R7. HEAD on an LDPR</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
- </p>
<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>Assertions</h4>
<ul>
<li>Assert <Response 1 HEAD> (HEAD correct):
<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>
</div>
<hr/>
<h2><a id="Tests-LDPCs"></a>Tests for LDPCs</h2>
<p>These tests involve LDPCs and LDPRs.</p>
<div resource="#TCC1" typeof="td:TestCase">
<h3><a id="TC-C1">TC-C1. GET on an LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
- </p>
<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>Assertions</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>
</ul>
</div>
<hr/>
<div resource="#TCC2" typeof="td:TestCase">
<h3><a id="TC-C2">TC-C2. GET on an LDPC without content type</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
- </p>
<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>Assertions</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>
</ul>
</div>
<hr/>
<div resource="#TCC3" typeof="td:TestCase">
<h3><a id="TC-C3">TC-C3. GET on a non-existing LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
- </p>
<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>Assertions</h4>
<ul>
<li>Assert <Response 1 GET> (GET incorrect):
<ul>
<li>[Status-Line].Status-Code = 404 or 410</li>
</ul>
</li>
</ul>
</div>
<hr/>
<div resource="#TCC4" typeof="td:TestCase">
<h3><a id="TC-C4">TC-C4. PUT on an LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
+ </p>
<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.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>Assertions</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>
</div>
<hr/>
<div resource="#TCR6" typeof="td:TestCase">
<h3><a id="TC-R6">TC-R6. DELETE on an LDPR</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
+ </p>
<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.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>Assertions</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>
</ul>
</div>
<hr/>
<div resource="#TCR7" typeof="td:TestCase">
<h3><a id="TC-R7">TC-R7. HEAD on an LDPR</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
+ </p>
<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.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>Assertions</h4>
<ul>
<li>Assert <Response 1 HEAD> (HEAD correct):
<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>
</div>
<hr/>
<h2><a id="Tests-LDPCs"></a>Tests for LDPCs</h2>
<p>These tests involve LDPCs and LDPRs.</p>
<div resource="#TCC1" typeof="td:TestCase">
<h3><a id="TC-C1">TC-C1. GET on an LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
+ </p>
<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>
<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>Assertions</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>
</ul>
</div>
<hr/>
<div resource="#TCC2" typeof="td:TestCase">
<h3><a id="TC-C2">TC-C2. GET on an LDPC without content type</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
+ </p>
<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.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>Assertions</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>
</ul>
</div>
<hr/>
<div resource="#TCC3" typeof="td:TestCase">
<h3><a id="TC-C3">TC-C3. GET on a non-existing LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
+ </p>
<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.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>Assertions</h4>
<ul>
<li>Assert <Response 1 GET> (GET incorrect):
<ul>
<li>[Status-Line].Status-Code = 404 or 410</li>
</ul>
</li>
</ul>
</div>
<hr/>
<div resource="#TCC4" typeof="td:TestCase">
<h3><a id="TC-C4">TC-C4. PUT on an LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
</p>
<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>Assertions</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>
</div>
<hr/>
<div resource="#TCC5" typeof="td:TestCase">
<h3><a id="TC-C5">TC-C5. PUT on an LDPC without matching ETags</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
- </p>
<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>Assertions</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>
</div>
<hr/>
<div resource="#TCC6" typeof="td:TestCase">
<h3><a id="TC-C6">TC-C6. DELETE on an LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
- </p>
<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>Assertions</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>
</ul>
</div>
<hr/>
<div resource="#TCC7" typeof="td:TestCase">
<h3><a id="TC-C7">TC-C7. DELETE on an LDPR in an LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
- </p>
<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>Assertions</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>
</div>
<hr/>
<div resource="#TCC8" typeof="td:TestCase">
<h3><a id="TC-C8">TC-C8. HEAD on an LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
- </p>
<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>Assertions</h4>
<ul>
<li>Assert <Response 1 HEAD> (HEAD correct):
<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>
</div>
<hr/>
<div resource="#TCC9" typeof="td:TestCase">
<h3><a id="TC-C9">TC-C9. POST an LDPR on an LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
- </p>
<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>GET <LDPC URI>
<ul>
<li>[request-header].Accept = text/turtle</li>
</ul>
</li>
<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 2 POST>.[response-header].Location
<ul>
<li>[request-header].Accept = text/turtle</li>
</ul>
</li>
</ol>
<h4>Output</h4>
<ul>
<li> <em><em> <Response 1 GET></em></em></li>
<li><em><em></em><Response 2 POST></em></li>
<li> <em> <Response 3 GET></em></li>
<li> <em> <Response 4 GET></em></li>
</ul>
<h4>Assertions</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 1 GET> (container does not have member):
<ul>
<li>[message-body] does not contain a member identified by <Response 2
POST>.[response-header].Location</li>
</ul>
</li>
<li>Assert <Response 2 POST> (POST correct):
<ul>
<li>[Status-Line].Status-Code = 201</li>
<li>[response-header].Location exists</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> (container has member):
<ul>
<li>[message-body] contains a member identified by <Response 2 POST>.[response-header].Location</li>
</ul>
</li>
<li>Assert <Response 4 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>
</div>
<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> 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. <br/>
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. <br/>
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. <br/>
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. </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. <br/>
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”. <br/>
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”. </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>Annotate all tests following the sample RDFa annotation.</li>
<li>Choose a namespace for the new vocabulary terms and for the test cases</li>
<li>Include the RDF description of the test suite</li>
<li>Implement validator</li>
<li>Format document as a specification</li>
<li>Check format of examples</li>
<li>Add references</li>
</ul>
</body>
</html>
\ No newline at end of file
+ </p>
<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.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> <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>Assertions</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>
</div>
<hr/>
<div resource="#TCC6" typeof="td:TestCase">
<h3><a id="TC-C6">TC-C6. DELETE on an LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
+ </p>
<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.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>Assertions</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>
</ul>
</div>
<hr/>
<div resource="#TCC7" typeof="td:TestCase">
<h3><a id="TC-C7">TC-C7. DELETE on an LDPR in an LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
+ </p>
<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>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>Assertions</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>
</div>
<hr/>
<div resource="#TCC8" typeof="td:TestCase">
<h3><a id="TC-C8">TC-C8. HEAD on an LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
+ </p>
<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.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>Assertions</h4>
<ul>
<li>Assert <Response 1 HEAD> (HEAD correct):
<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>
</div>
<hr/>
<div resource="#TCC9" typeof="td:TestCase">
<h3><a id="TC-C9">TC-C9. POST an LDPR on an LDPC</a></h3>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span
property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed
+ </p>
<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>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>GET <LDPC URI>
<ul>
<li>[request-header].Accept = text/turtle</li>
</ul>
</li>
<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 2 POST>.[response-header].Location
<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 POST></em></li>
<li> <em> <Response 3 GET></em></li>
<li> <em> <Response 4 GET></em></li>
</ul>
<h4>Assertions</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 1 GET> (container does not have member):
<ul>
<li>[message-body] does not contain a member identified by <Response 2
POST>.[response-header].Location</li>
</ul>
</li>
<li>Assert <Response 2 POST> (POST correct):
<ul>
<li>[Status-Line].Status-Code = 201</li>
<li>[response-header].Location exists</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> (container has member):
<ul>
<li>[message-body] contains a member identified by <Response 2 POST>.[response-header].Location</li>
</ul>
</li>
<li>Assert <Response 4 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>
</div>
<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> 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. <br/>
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. <br/>
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. <br/>
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. </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. <br/>
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”. <br/>
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”. </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><a target="_blank" href="http://www.w3.org/TR/ldp/">Linked Data Platform 1.0</a></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="ChangeHistory">Change history</a></h2>
<ul>
<li>2013-06-03 Implemented <a href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0153.html">changes suggested by Eric Prud'hommeaux</a> (RGC)</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>Annotate all tests following the sample RDFa annotation</li>
<li>Choose a namespace for the new vocabulary terms and for the test cases</li>
<li>Include the RDF description of the test suite</li>
<li>Implement validator</li>
<li>Format document as a specification</li>
<li>Check format of examples</li>
<li>Add references</li>
</ul>
</body>
</html>
\ No newline at end of file