--- a/tests/ldp-testsuite.html Mon Jul 07 11:27:00 2014 -0400
+++ b/tests/ldp-testsuite.html Mon Jul 07 12:06:45 2014 -0400
@@ -1,3 +1,3 @@
-<?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-2.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 http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<!-- rgarcia: Had to uncomment it so it can read the local image
<base href="http://www.w3.org/TR/ldp/TestCases">-->
<title>Linked Data Platform 1.0 Test Cases</title>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
class='remove' async></script>
<script class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus : "NOTE",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName : "ldp-testsuite",
// TODO: Confirm short name
// if your specification has a subtitle that goes below the main
// formal title, define it here
// subtitle : "an excellent document",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
// if the specification's copyright date is a range of years, specify
// the start date here:
// copyrightStart: "2005"
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
//previousPublishDate: "2013-03-07",
//previousMaturity: "FPWD",
//previousURI: "http://www.w3.org/TR/2013/WD-ldp-20130307/",
// if there a publicly available Editor's Draft, this is the link
//edDraftURI: "http://www.w3.org/2012/ldp/hg/ldp.html",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// if you want to have extra CSS, append them to this list
// it is recommended that the respec.css stylesheet be kept
//extraCSS: ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],
// editors, add as many as you like
// only "name" is required
editors : [
{
name : "Raúl García-Castro",
url : "http://www.garcia-castro.com/",
company : "Ontology Engineering Group, Universidad Politécnica de Madrid",
companyURL : "http://www.oeg-upm.net/"
},
{
name : "Fernando Serena",
company : "Ontology Engineering Group, Universidad Politécnica de Madrid",
companyURL : "http://www.oeg-upm.net/"
},
{ name: "Steve Speicher", url: "http://stevespeicher.blogspot.com",
company: "IBM Corporation", companyURL: "http://ibm.com/"
}
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
//authors: [
// { name: "Your Name", url: "http://example.org/",
// company: "Your Company", companyURL: "http://example.com/" },
//],
// name of the WG
wg : "Linked Data Platform Working Group",
// URI of the public WG page
wgURI : "http://www.w3.org/2012/ldp",
// name (without the @w3c.org) of the public mailing to which comments are due
wgPublicList : "public-ldp-wg",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI : "http://www.w3.org/2004/01/pp-impl/55082/status",
doRDFa : "1.1",
+<?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-2.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
prefix="td: http://www.w3.org/2006/03/test-description# ldpt: http://www.w3.org/ns/ldp/test#">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<!-- rgarcia: Had to uncomment it so it can read the local image
<base href="http://www.w3.org/TR/ldp/TestCases">-->
<title>Linked Data Platform 1.0 Test Cases</title>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
class='remove' async></script>
<script class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus : "unofficial",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName : "ldp-testsuite",
// TODO: Confirm short name
// if your specification has a subtitle that goes below the main
// formal title, define it here
// subtitle : "an excellent document",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
// if the specification's copyright date is a range of years, specify
// the start date here:
// copyrightStart: "2005"
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
//previousPublishDate: "2013-03-07",
//previousMaturity: "FPWD",
//previousURI: "http://www.w3.org/TR/2013/WD-ldp-20130307/",
// if there a publicly available Editor's Draft, this is the link
//edDraftURI: "http://www.w3.org/2012/ldp/hg/ldp.html",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// if you want to have extra CSS, append them to this list
// it is recommended that the respec.css stylesheet be kept
//extraCSS: ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],
// editors, add as many as you like
// only "name" is required
editors : [
{
name : "Raúl García-Castro",
url : "http://www.garcia-castro.com/",
company : "Ontology Engineering Group, Universidad Politécnica de Madrid",
companyURL : "http://www.oeg-upm.net/"
},
{
name : "Fernando Serena",
company : "Ontology Engineering Group, Universidad Politécnica de Madrid",
companyURL : "http://www.oeg-upm.net/"
},
{ name: "Steve Speicher", url: "http://stevespeicher.blogspot.com",
company: "IBM Corporation", companyURL: "http://ibm.com/"
}
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
//authors: [
// { name: "Your Name", url: "http://example.org/",
// company: "Your Company", companyURL: "http://example.com/" },
//],
// name of the WG
wg : "Linked Data Platform Working Group",
// URI of the public WG page
wgURI : "http://www.w3.org/2012/ldp",
// name (without the @w3c.org) of the public mailing to which comments are due
wgPublicList : "public-ldp-wg",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI : "http://www.w3.org/2004/01/pp-impl/55082/status",
doRDFa : "1.1",
localBiblio: {
"LDP-PRIMER": {
title: "Linked Data Platform 1.0 Primer",
href: "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html",
authors: [
"Nandana Mihindukulasooriya",
- "Roger Menday"
],
status: "WD",
deliveredBy: [
"http://www.w3.org/2012/ldp/"
],
publisher: "W3C"
},
"LDP-TESTCASES": {
title: "Linked Data Platform Test Cases",
href: "http://w3c.github.io/ldp-testsuite/",
deliveredBy: [
"http://www.w3.org/2012/ldp/"
]
},
"LDP-TESTSUITE-COVERAGE": {
title: "Linked Data Platform Test Suite Coverage",
href: "http://w3c.github.io/ldp-testsuite/report/ldp-testsuite-coverage-report.html",
deliveredBy: [
"http://www.w3.org/2012/ldp/"
]
},
"LDP-IMPL": {
title: "Linked Data Platform Implementation Reports",
href: "https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/reports/ldp.html",
deliveredBy: [
"http://www.w3.org/2012/ldp/"
]
},
}
};
</script>
</head>
<body>
<section id='abstract'>
<p>The Linked Data Platform specification, informally LDP,
describes the use of HTTP for accessing, updating, creating and
deleting resources from servers that expose their resources as Linked
Data. This document describes the conditions that LDP servers must
satisfy in order to be conformant with the specification and presents
a common format for describing LDP test results.
These test cases both illustrate the features of the specification and
can be used for testing conformance. [[LINKED-DATA-PLATFORM]]</p>
</section>
<section id='sotd'>
<p>
<!--Empty. Nothing else to add.-->
</p>
</section>
<section>
<h2>
Introduction
</h2>
<p>
This document describes a test suite that can be used to evaluate the
conformance of LDP servers to the LDP specification
[[LINKED-DATA-PLATFORM]]. The document also presents the design
principles that guided the development of the test suite, a testing
process, and a common format for describing test results.
<br/> The purpose of the test cases is to illustrate the
specification features and to help in testing conformance. The
provided set of test cases is "incomplete" in the sense that passing
all the tests does not prove that a given system conforms to the LDP
specification; failing a test does, however, prove that the system
does not conform to the specification.
<br/> The presented format is intended to facilitate the use of
tests by LDP server developers, e.g., in a test harness, as well as
the extension of the test suite with new tests. Developers can check
the LDP Primer [[LDP-PRIMER]] for concrete examples of inputs and
expected outputs that can be used for testing.
</p>
</section>
<section>
<h2>
Design principles
</h2>
<section>
<h3>
Generic vs domain-specific servers
</h3>
<p>There will be two types of servers implementing the LDP
specification:</p>
<ul>
<li>Generic 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>Servers exposing their data using the LDP specification.
These servers impose restrictions on LDPRs since they have an
underlying business logic and data model.</li>
</ul>
<p>In order to cover both types of servers, there are some basic input
data and a way to provide
specific input data in the test suite. It is up to the evaluator to
define specific input data for a certain server. Evaluators must
include these input data along with the results when reporting the
results of a certain server.</p>
</section>
<section>
<h3>
Protocol evaluation vs data evaluation
</h3>
<p>The LDP specification includes restrictions on LDP servers at
the protocol level and at the data level. Currently, the restrictions
at the data level are minimal and servers are not forced to have a
certain behavior 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 <code>rdf:type</code> 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>
</section>
<section>
<h3>
Test suite coverage
</h3>
<p>
This test suite covers those requirements present in the
LDP specification of any compliance level: MUST, SHOULD and MAY. 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, patch formats).</p>
<p>
Furthermore, the LDP specification [[LINKED-DATA-PLATFORM]] contains
a number of requirements that can not validated by automated means,
these are identified in a coverage report for the [[LINKED-DATA-PLATFORM]].
</p>
</section>
<section>
<h3>Separation of results and assertions</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>
</section>
<section>
<h3>Traceability of test cases</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>
</section>
</section>
<section>
<h2>Testing process</h2>
<p>The LDP Test Cases are defined in a location, within Java source code. [[LDP-TESTCASES]]
Details about each individual test case, such as information about
whether it can be executed by automated means, manual, client only.
Also on the status of each test case, such as approved by the LDP
Working Group, awaiting approval or not yet implemented.[[LDP-TESTSUITE-COVERAGE]]</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. 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
supplied as defined in the document on implementation reports. [[LDP-IMPL]]</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. [[LDP-IMPL]]</li>
</ol>
<p><object data="TestingProcess.svg" type="image/svg+xml">Your
browser does not support SVG.</object>
</p>
</section>
<section>
<h2>Describing testing artifacts in RDF</h2>
<section>
<h3>Namespaces used</h3>
<p>
The following vocabularies are reused for describing the testing
artifacts: DOAP (
<code>doap</code>
), Dublin Core (
<code>dc</code>
) [[DC11]], FOAF (
<code>foaf</code>
) [[FOAF]], HTTP Vocabulary in RDF (
<code>ht</code>
) [[HTTP-IN-RDF]], and W3C Test Metadata (
<code>td</code>
) [[TEST-METADATA]].
</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> </section> <!--
<section>
<h3><a id="TestSuiteDescription">Test suite description</a></h3>
<p><em>To be completed</em></p>
</section>
--> <section>
<h3>
Test case description
</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="step">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>
<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.2.8 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.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]".
],
[
a tn:Excerpt;
rdfs:seeAlso <http://www.w3.org/TR/ldp/>;
tn:includesText "4.3.1 LDPR servers MUST support the HTTP GET Method for LDPRs.".
];
td:input :TCR1-I1-LDPR-URI;
td:precondition "The LDP server contains an LDPR at <LDPR URI>";
tn:output :TCR1-O1-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://www.garcia-castro.com/#me>.
:TCR1-I1-LDPR-URI a tn:TestInput;
dc:title "<LDPR URI>";
dc:description "The URI of an LDPR".
:TCR1-O1-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>";
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
[response-header].Link includes ldp:Resource; rel="type"""".
</pre> </section> <section>
<h3>
Execution report description
</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>
<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-O1-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> </section> <section>
<h3>
Test case assertion description
</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>
<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> </section> </section>
</section>
</section>
<section class="appendix">
<h2>Change history</h2>
<ul>
<li>2014-06-22 Brought inline with separate automated testsuite hosted on GitHub (SS)</li>
<li>2014-04-09 Updated according to Last Call Working Draft from 11 March 2014 (FS and RGC)</li>
<li>2013-08-27 Updated according to Last Call Working Draft from 30 July 2013 (RGC)</li>
<li>2013-06-03 Updated to use ReSpec (RGC)</li>
<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>
</section>
<section class="appendix">
<h2>Editor TODOs and notes</h2>
<ul>
<li>Define the type of document: Working Draft, Note, etc.</li>
<li>Choose a URI for the test cases (this) document</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>
</ul>
</section>
</body>
</html>
\ No newline at end of file
+ "Roger Menday"
],
status: "WD",
deliveredBy: [
"http://www.w3.org/2012/ldp/"
],
publisher: "W3C"
},
"LDP-TESTCASES": {
title: "Linked Data Platform Test Cases",
href: "http://w3c.github.io/ldp-testsuite/",
deliveredBy: [
"http://www.w3.org/2012/ldp/"
]
},
"LDP-TESTSUITE-COVERAGE": {
title: "Linked Data Platform Test Suite Coverage",
href: "http://w3c.github.io/ldp-testsuite/report/ldp-testsuite-coverage-report.html",
deliveredBy: [
"http://www.w3.org/2012/ldp/"
]
},
"LDP-IMPL": {
title: "Linked Data Platform Implementation Reports",
href: "https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/reports/ldp.html",
deliveredBy: [
"http://www.w3.org/2012/ldp/"
]
},
}
};
</script>
</head>
<body>
<section id='abstract'>
<p>The Linked Data Platform specification, informally LDP,
describes the use of HTTP for accessing, updating, creating and
deleting resources from servers that expose their resources as Linked
Data. This document describes the conditions that LDP servers must
satisfy in order to be conformant with the specification and presents
a common format for describing LDP test results.
These test cases both illustrate the features of the specification and
can be used for testing conformance. [[LINKED-DATA-PLATFORM]]</p>
</section>
<section id='sotd'>
<p>
<!--Empty. Nothing else to add.-->
</p>
</section>
<section>
<h2>Introduction</h2>
<p>
This document describes a test suite that can be used to evaluate the
conformance of LDP servers to the LDP specification
[[LINKED-DATA-PLATFORM]]. The document also presents the design
principles that guided the development of the test suite, a testing
process, and a common format for describing test results.</p>
<p>The purpose of the test cases is to illustrate the
specification features and to help in testing conformance. The
provided set of test cases is "incomplete" in the sense that passing
all the tests does not prove that a given system conforms to the LDP
specification; failing a test does, however, prove that the system
does not conform to the specification.</p>
<p>The presented format is intended to facilitate the use of
tests by LDP server developers, e.g., in a test harness, as well as
the extension of the test suite with new tests. Developers can check
the LDP Primer [[LDP-PRIMER]] for concrete examples of inputs and
expected outputs that can be used for testing.
</p>
</section>
<section>
<h2>Design principles</h2>
<section>
<h3>Generic vs domain-specific servers</h3>
<p>There will be two types of servers implementing the LDP
specification:</p>
<ul>
<li>Generic 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>Servers exposing their data using the LDP specification.
These servers impose restrictions on LDPRs since they have an
underlying business logic and data model.</li>
</ul>
<p>In order to cover both types of servers, there are some basic input
data and a way to provide
specific input data in the test suite. It is up to the evaluator to
define specific input data for a certain server. Evaluators must
include these input data along with the results when reporting the
results of a certain server.</p>
</section>
<section>
<h3>Protocol evaluation vs data evaluation</h3>
<p>The LDP specification includes restrictions on LDP servers at
the protocol level and at the data level. Currently, the restrictions
at the data level are minimal and servers are not forced to have a
certain behavior when processing LDPR representations. Therefore, the
test suite evaluates LDP servers mostly at a protocol level; the only
exception is in the case of LDPCs, since they are required to include
a <code>rdf:type</code>, containment and membership statements 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>
</section>
<section>
<h3>Test suite coverage</h3>
<p>
This test suite covers those requirements present in the
LDP specification of any compliance level: MUST, SHOULD and MAY. 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, patch formats).</p>
<p>
Furthermore, the LDP specification [[LINKED-DATA-PLATFORM]] contains
a number of requirements that can not validated by automated means,
these are identified in a coverage report for the [[LINKED-DATA-PLATFORM]].
These requirements will need to be validated by some non-automatic method
and results evaluated.
</p>
</section>
<section>
<h3>Separation of results and assertions</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>
</section>
<section>
<h3>Traceability of test cases</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>
</section>
</section>
<section>
<h2>Testing process</h2>
<p>The LDP Test Cases are defined in a location, within Java source code. [[LDP-TESTCASES]]
Details about each individual test case, such as information about
whether it can be executed by automated means, manual or client only,
will be found in the Java source code annotations.
Also in the Java source code annotations the status of each test case, such as approved by the LDP
Working Group, awaiting approval or not yet implemented.[[LDP-TESTSUITE-COVERAGE]]</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. 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
supplied as defined in the document on implementation reports. [[LDP-IMPL]]</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. [[LDP-IMPL]]</li>
</ol>
<p><object data="TestingProcess.svg" type="image/svg+xml">Your
browser does not support SVG.</object>
</p>
</section>
<section>
<h2>Describing testing artifacts in RDF</h2>
<section>
<h3>Namespaces used</h3>
<p>
The following vocabularies are reused for describing the testing
artifacts: DOAP (
<code>doap</code>
), Dublin Core (
<code>dcterms</code>
) [[DC11]], FOAF (
<code>foaf</code>
) [[FOAF]], and W3C Test Metadata (
<code>td</code>
) [[TEST-METADATA]].
</p>
<p>
All the new required entities that are not covered by those
vocabularies have been defined under a new namespace (
<code>ldpt</code>
), as well as the LDP test cases.
</p>
<p>Next we present the definition of these namespaces and of all
the namespaces used in the examples.</p>
<pre>dcterms: <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/>
mf: <http://www.w3.org/2001/sw/DataAccess/tests/test-manifest#>
rdfs: <http://www.w3.org/2000/01/rdf-schema#>
rdft: <http://www.w3.org/ns/rdftest#>
td: <http://www.w3.org/2006/03/test-description#>
ldpt: <http://www.w3.org/ns/ldp/test#></pre> </section>
<section>
<h3>Test case description</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>mf:name</code>. Like <code>rdfs:label</code> but less human
focus.</li>
<li><code>dcterms:title</code>. The name of the test.</li>
<li><code>dcterms:description</code>. The description of the test.</li>
<li><code>dcterms:contributor</code>. The person (<code>foaf:Person</code>)
contributing the test.</li>
<li><code>dcterms:subject</code>. The grouping of test or compliance level.</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>
</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>The following example contains the description of one of the LDP
test cases.</p>
<pre class="example" id="test-case-example">ldpt:CommonResource-GetResource a td:TestCase;
rdfs:label "CommonResource-GetResource";
mf:name "CommonResource-GetResource";
dcterms:title "GET on an LDPR";
dcterms:description "Tests making a GET request on an existing LDPR";
dcterms:contributor :RaulGarciaCastro;
td:reviewStatus td:approved;
rdfs:seeAlso <http://www.w3.org/TR/ldp#ldpr-get-must>;
dcterms:subject "MUST" ;
td:specificationReference [
a tn:Excerpt;
rdfs:seeAlso <http://www.w3.org/TR/ldp#ldpr-get-must>;
tn:includesText "LDP servers MUST support the HTTP GET Method for LDPRs".
].
:RaulGarciaCastro a foaf:Person;
rdfs:label "Raúl García-Castro";
owl:sameAs <http://www.garcia-castro.com/#me>.</pre>
</section>
<section>
<h3>
Test case assertion description
</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>dcterms: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>earl:mode</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>
<pre class="example" id="test-assertion-example">:TCR1-Assertion-SomeServer a earl:Assertion;
earl:subject :AwesomeLDP;
earl:test ldpt:CommonResource-GetResource;
earl:assertedBy :AwesomeLDP;
earl:mode: earl:automatic;
earl:result [
a earl:OutcomeValue ;
dcterms:date "2014-07-06T09:30:10";
earl:outcome earl:passed
].
:AwesomeLDP a doap:Project, earl:TestSubject, earl:Software, earl:Assertor;
doap:name "Awesome LDP";
doap:description "Awesome LDP implementation";
doap:developer [ a foaf:Person ;
foaf:mbox "awesomeldp@example.org" ;
foaf:name "Dope Developer"
];
doap:homepage <http://example.org/AwesomeLDP>;
doap:programming-language "JavaScript".</pre>
</section>
</section>
</section>
</section>
<section class="appendix">
<h2>Change history</h2>
<ul>
<li>2014-07-07 Further alignment with current testing approach and namespaces (SS)</li>
<li>2014-06-22 Brought inline with separate automated testsuite hosted on GitHub (SS)</li>
<li>2014-04-09 Updated according to Last Call Working Draft from 11 March 2014 (FS and RGC)</li>
<li>2013-08-27 Updated according to Last Call Working Draft from 30 July 2013 (RGC)</li>
<li>2013-06-03 Updated to use ReSpec (RGC)</li>
<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>
</section>
<section class="appendix">
<h2>Editor TODOs and notes</h2>
<ul>
<li>Define the type of document: Working Draft, Note, etc.</li>
<li>Choose a URI for the test cases (this) document</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>
</ul>
</section>
</body>
</html>
\ No newline at end of file