Initial prep for ldp-paging for CR
authorSteve Speicher <sspeiche@gmail.com>
Wed, 05 Nov 2014 11:13:36 -0500
changeset 869 ecb7b6549780
parent 868 e9a9e93c1ea9
child 870 f07f6c192ac7
Initial prep for ldp-paging for CR
ldp-paging.html
tests/ldp-paging-testsuite.html
tests/ldp-testsuite.html
--- a/ldp-paging.html	Wed Nov 05 08:01:03 2014 -0500
+++ b/ldp-paging.html	Wed Nov 05 11:13:36 2014 -0500
@@ -1,22 +1,9 @@
-
 <!DOCTYPE html>
 <!-- 
-	DONE: http://www.w3.org/2013/meeting/ldp/2014-04-15#resolution_7 : At a minimum, on paging, we'll provide a way for clients to detect that a triple fell through the cracks during paging.
-	DONE: http://www.w3.org/2013/meeting/ldp/2014-04-17 resolution 3: spec sandro's paging proposal
-	DONE: http://www.w3.org/2012/ldp/track/issues/94 -> http://www.w3.org/2013/meeting/ldp/2014-05-12#resolution_3 2014-04-17 resolution 3: spec sandro's paging proposal
-	DONE: STARTED: http://www.w3.org/2013/meeting/ldp/2014-04-17 resolution 4: page size hint
-	DONE: http://www.w3.org/2013/meeting/ldp/2014-04-17 resolution 5: contains+member triple always on same page
-	DONE: http://www.w3.org/2013/meeting/ldp/2014-05-12 resolution 4: ordering undefined when paging non-LDPC LDPRs
-	
-	DONE: Missing link header for equivalent of ldp:pageOf? Need to verify.  Also we have ldp-paging:pageOf in samples
-			but it doesn't exist in rules or vocabulary doc, oversight?
-	DONE: Sandro 7/29: loosen up restrictions on target of pageSequence link
 	TODO: Once companion documents (best practices, primer) have URLs, link to them.  Search on "companion".
-	TODO: Mine Jim des Riv May 21 email for more content
 	TODO: Example 11 is missing ldp:contains, true?  Omit due to GET on page resource, should make it more clear.
 	TODO: Paging intro: add 3rd example showing header linkage amongst pages and (HEAD on) the base resource.
      Maybe also insert HEAD on base as new first example instead of relying on text alone.
-    DONE: Missing namespace definition clause?
  -->
 <html>
   <head>
@@ -31,7 +18,7 @@
     <script class='remove'>
       var respecConfig = {
           // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
-          specStatus:           "WD",
+          specStatus:           "CR",
           
           // the specification's short name, as in http://www.w3.org/TR/short-name/
           shortName:            "ldp-paging",
@@ -41,7 +28,7 @@
           // subtitle   :  "an excellent document",
 
           // if you wish the publication date to be other than today, set this
-          //publishDate:  "2014-09-09",
+          publishDate:  "2014-11-13",
 
           // if the specification's copyright date is a range of years, specify
           // the start date here:
@@ -50,7 +37,7 @@
           // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
           // and its maturity status
           previousPublishDate:  "2014-09-09",
-          previousMaturity:  	"LC",
+          previousMaturity:  	"WD",
           previousURI: 			"http://www.w3.org/TR/2014/WD-ldp-20140909/",
           
           processVersion: 		2005,
@@ -132,15 +119,15 @@
 				,   status:   "Internet-Draft"
 				,   publisher:  "IETF"
 				},
-				"LDP-Tests": {
-					title:    "Linked Data Platform 1.0 Test Cases"
-				,   href:     "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html"
+				"LDP-Paging-Tests": {
+					title:    "Linked Data Platform Paging 1.0 Test Cases"
+				,   href:     "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-paging-testsuite.html"
 				,   authors:  [
 						"R. Garcia-Castro", "F. Serena"
 					]
 				,   status:   "Editor's Draft of Working Group Note"
 				,   publisher:  "W3C"
-				},
+				},				
 				"REL-CANONICAL": {
 					title:    "The Canonical Link Relation"
 				,   href:     "http://tools.ietf.org/html/rfc6596"
@@ -2216,11 +2203,16 @@
 
 <section class='appendix informative' id="history">
 <h1>Change History</h1>
+<!-- 
 <p>The change history is up to the editors to insert a brief summary of
 changes, ordered by most recent changes first and with heading from which
 public draft it has been changed from.
-</p>
+</p>  -->
 
+<em>Summary</em>
+<ul>
+	<li></li>
+</ul>
 <!-- 
 <em>Summary</em>
 <ul>
@@ -2238,7 +2230,7 @@
 </p>  -->
 
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
-
+<!-- 
 <ul>
 	<li>2014-10-10 - Clarified "new protocol" in 4.2, hyper-linked max-member-count to LDPCs per 10/10 public comments email (JA) </li>
 	<li>2014-09-26 - Added non-norm items about extensions to supply client requested ordering (SS) </li>
@@ -2281,6 +2273,7 @@
 	<li>2014-02-18 - Split off LDP-Paging from LDP (SS) </li>
 </ul>
 <blockquote><em><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/94420c5678ae/ldp.html">February 18, 2014 Editor's Draft</a></em></blockquote>
+ -->
 </section>
     
   </body>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tests/ldp-paging-testsuite.html	Wed Nov 05 11:13:36 2014 -0500
@@ -0,0 +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# 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 Paging 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-paging-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: "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:     "http://www.w3.org/TR/ldp-primer/",
			        authors:  [
			            "Nandana Mihindukulasooriya",
+			            "Roger Menday"
			        ],
			        status:   "NOTE",
			        deliveredBy: [
                        "http://www.w3.org/2012/ldp/"
                    ],
			        publisher:  "W3C"
		    },
		    "LDP-PAGING-TESTCASES": {
		        title:    "Linked Data Platform Paging 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/manifest",
		        deliveredBy: [
                    "http://www.w3.org/2012/ldp/"
                ]
		    },
		    "LDP-TESTSUITE": {
		        title:    "Linked Data Platform 1.0 Test Suite",
		        href:     "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html",
		        deliveredBy: [
                    "http://www.w3.org/2012/ldp/"
                ]
		    },
		    "LDP-PAGING-TESTSUITE-COVERAGE": {
		        title:    "Linked Data Platform Paging Test Suite Coverage",
		        href:     "http://w3c.github.io/ldp-testsuite/manifest/paging",
		        deliveredBy: [
                    "http://www.w3.org/2012/ldp/"
                ]
		    },		    
		    "LDP-PAGING-CONFORM": {
		        title:    "Linked Data Platform Paging Implementation Conformance Report",
		        href:     "https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/reports/paging/ldp-paging.html",
		        deliveredBy: [
                    "http://www.w3.org/2012/ldp/"
                ]
		    },
	    }
	};
</script>
</head>
<body>

	<section id='abstract'>
	<p>The Linked Data Platform Paging specification, informally LDP-Paging,
		describes a HTTP-based protocol for clients and servers to be able to 
		efficiently retrieve large Linked Data Platform Resource representations 
		by splitting up the responses into separate URL-addressable page resources.. 
		This document describes the approach and references to the conditions that LDP-Paging servers must
		satisfy in order to be conformant with the specification and presents
		a common format for describing LDP-Paging test results.
		These test cases both illustrate the features of the specification and
		can be used for testing conformance. [[LDP-PAGING]]</p>
	</section>

	<section id='sotd'>
      <p>
      <!--Empty. Nothing else to add.-->
      </p>
    </section>

	<section>
	<h2>Introduction</h2>
	<p>
		This document introduces a test suite that can be used to evaluate the
		conformance of LDP-Paging servers to the LDP-Paging specification
		[[LDP-PAGING]]. The test suite leverages the testing approach
		used for the Linked Data Platform specification [[LDP-TESTSUITE]].</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-Paging
		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-Paging 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>
	<p>The design principles match that from the LDP test suite [[LDP-TESTSUITE]].  
	The goal is to automate as much as possible, though there will be cases when the automated tests
	may not be enough and some manual validation will be needed.
	</p>

	</section>

	<section>
	<h2>Testing process</h2>
	<p>Like the LDP Test Cases, the LDP-Paging Test Cases are defined in a location, within Java source code. [[LDP-PAGING-TESTCASES]]
		Details about each individual test case, such as information about
		whether it can be attempted by automated means or manual,
		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-PAGING-TESTSUITE-COVERAGE]]</p>
	<ol>
		<li>The person or agent in charge of executing the test cases in
			a specific LDP-Paging server will take the test case definitions and run
			every test case on the LDP-Paging server.  The execution of test
			cases must produce a test execution report for the LDP-Paging 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 conformance reports. [[LDP-PAGING-CONFORM]]</li>
		<li>A report generator software will take all the LDP-Paging server
			execution reports and will generate an implementation report that
			includes the results of all the LDP-Paging servers. [[LDP-PAGING-CONFORM]]</li>
	</ol>

	<section>
	<h2>Submitting results</h2>
	<p>Here is a summary of the steps needed for an assertor to submit the compliance results for an implementation.</p>
	<ul>
		<li>Run the automated test suite [[LDP-PAGING-TESTCASES]]</li>
		<li>Run the manual tests and update the results within the same EARL results file</li>
		<li>Email results file (at minimum) EARL file (Turtle preferred) to <a href="mailto:[email protected]">[email protected]</a>.  Be sure to indicate if this is intended to
		replace any previously submitted results.  It is also helpful to indicate if these are preliminary results and that plans are to submit additional progress in the future.</li>
	</ul>
	</section>
	
	</section>

	<section>
	<h2>Describing testing artifacts in RDF</h2>
	<p>See details in LDP Test Suite [[LDP-TESTSUITE]].</p>
	</section>

	</section>

	<section class="appendix">
	<h2>Change history</h2>
	<ul>
		<li>2014-11-05 Created initial revision based on LDP test suite (SS)</li>	
	</ul>
	</section>

</body>
</html>
\ No newline at end of file
--- a/tests/ldp-testsuite.html	Wed Nov 05 08:01:03 2014 -0500
+++ b/tests/ldp-testsuite.html	Wed Nov 05 11:13:36 2014 -0500
@@ -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# 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:     "http://www.w3.org/TR/ldp-primer/",
			        authors:  [
			            "Nandana Mihindukulasooriya",
-			            "Roger Menday"
			        ],
			        status:   "NOTE",
			        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-CONFORM": {
		        title:    "Linked Data Platform Implementation Conformance Report",
		        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 introduces 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 introduces 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>
		The 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 the 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 conformance reports. [[LDP-CONFORM]]</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-CONFORM]]</li>
	</ol>
	<p><object data="TestingProcess.svg" type="image/svg+xml">Your
			browser does not support SVG.</object>
	</p>
	
	<section>
	<h2>Submitting results</h2>
	<p>Here is a summary of the steps needed for an assertor to submit the compliance results for an implementation.</p>
	<ul>
		<li>Run the automated test suite [[LDP-TESTCASES]]</li>
		<li>Run the manual tests and update the results within the same EARL results file</li>
		<li>Email results file (at minimum) EARL file (Turtle preferred) to <a href="mailto:[email protected]">[email protected]</a>.  Be sure to indicate if this is intended to
		replace any previously submitted results.  It is also helpful to indicate if these are preliminary results and that plans are to submit additional progress in the future.</li>
	</ul>
	</section>
	
	</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: &lt;http://purl.org/dc/terms/&gt;
doap: &lt;http://usefulinc.com/ns/doap#&gt;
earl: &lt;http://www.w3.org/ns/earl#&gt;
foaf: &lt;http://xmlns.com/foaf/0.1/&gt;
mf: &lt;http://www.w3.org/2001/sw/DataAccess/tests/test-manifest#&gt;
rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;
rdft: &lt;http://www.w3.org/ns/rdftest#&gt;
td: &lt;http://www.w3.org/2006/03/test-description#&gt;
ldpt: &lt;http://www.w3.org/ns/ldp/test#&gt;</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 &lt;http://www.w3.org/TR/ldp#ldpr-get-must&gt;;
         dcterms:subject "MUST" ;
         td:specificationReference [
             a tn:Excerpt;
             rdfs:seeAlso &lt;http://www.w3.org/TR/ldp#ldpr-get-must&gt;;
             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 &lt;http://www.garcia-castro.com/#me&gt;.</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  "[email protected]" ;
						foaf:name  "Dope Developer"
                      ];
	doap:homepage	&lt;http://example.org/AwesomeLDP&gt;;
	doap:programming-language "JavaScript".</pre> 
            
    </section>
    </section>
	</section>
	</section>

	<section class="appendix">
	<h2>Change history</h2>
	<ul>
		<li>2014-08-25 Added section on submitting results and fixed references (SS)</li>	
		<li>2014-07-08 Various grammar fixes and removed todos (SS)</li>
		<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>

</body>
</html>
\ No newline at end of file
+			            "Roger Menday"
			        ],
			        status:   "NOTE",
			        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/manifest",
		        deliveredBy: [
                    "http://www.w3.org/2012/ldp/"
                ]
		    },
		    "LDP-CONFORM": {
		        title:    "Linked Data Platform Implementation Conformance Report",
		        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 introduces 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 introduces 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>
		The 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 the 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 or manually,
		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 conformance reports. [[LDP-CONFORM]]</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-CONFORM]]</li>
	</ol>
	<p><object data="TestingProcess.svg" type="image/svg+xml">Your
			browser does not support SVG.</object>
	</p>
	
	<section>
	<h2>Submitting results</h2>
	<p>Here is a summary of the steps needed for an assertor to submit the compliance results for an implementation.</p>
	<ul>
		<li>Run the automated test suite [[LDP-TESTCASES]]</li>
		<li>Run the manual tests and update the results within the same EARL results file</li>
		<li>Email results file (at minimum) EARL file (Turtle preferred) to <a href="mailto:[email protected]">[email protected]</a>.  Be sure to indicate if this is intended to
		replace any previously submitted results.  It is also helpful to indicate if these are preliminary results and that plans are to submit additional progress in the future.</li>
	</ul>
	</section>
	
	</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: &lt;http://purl.org/dc/terms/&gt;
doap: &lt;http://usefulinc.com/ns/doap#&gt;
earl: &lt;http://www.w3.org/ns/earl#&gt;
foaf: &lt;http://xmlns.com/foaf/0.1/&gt;
mf: &lt;http://www.w3.org/2001/sw/DataAccess/tests/test-manifest#&gt;
rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;
rdft: &lt;http://www.w3.org/ns/rdftest#&gt;
td: &lt;http://www.w3.org/2006/03/test-description#&gt;
ldpt: &lt;http://www.w3.org/ns/ldp/test#&gt;</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 &lt;http://www.w3.org/TR/ldp#ldpr-get-must&gt;;
         dcterms:subject "MUST" ;
         td:specificationReference [
             a tn:Excerpt;
             rdfs:seeAlso &lt;http://www.w3.org/TR/ldp#ldpr-get-must&gt;;
             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 &lt;http://www.garcia-castro.com/#me&gt;.</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  "[email protected]" ;
						foaf:name  "Dope Developer"
                      ];
	doap:homepage	&lt;http://example.org/AwesomeLDP&gt;;
	doap:programming-language "JavaScript".</pre> 
            
    </section>
    </section>
	</section>
	</section>

	<section class="appendix">
	<h2>Change history</h2>
	<ul>
		<li>2014-08-25 Added section on submitting results and fixed references (SS)</li>	
		<li>2014-07-08 Various grammar fixes and removed todos (SS)</li>
		<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>

</body>
</html>
\ No newline at end of file