Manifest details.

Sorry this took so long; it's pretty simple.

We're looking for a manifest file format to describe the RDFCore test
cases. This should let us -

- machine process the test case descriptions
- point to current copies of the test case input files on the web
- permit just the running (say) of parser tests
- permit the association of tests with particular issues
  (so we could just run the container tests, for instance)
- be in a simple-enough format that processing the manifest itself
  is not something that requires debugging
- be readily extensible to other types of test case as they arrive.

In addition, it was reckoned to be desirable that the whole test-case
directory structure plus manifest could be zipped up and shipped as an
item. Due to the handling of rdf:id attributes, this means we
potentially have to point to local copies of the test case files while
preserving information about their original base URIs.

1. A small taxonomy for test cases.

There are positive test cases (which should run to success) and negative
ones; a negative test case might illustrate where a parser might throw
an exception, or an entailment should _not_ be made.

(Required: the namespace "test" needs to live somewhere)


Currently test cases appear to be divided up into parser tests (which
generally take rdf/xml as input and compare the resulting graph with a
canonical version in ntriples) and entailment tests (where a number of
input files are processed and a check is performed to ensure that they
do, indeed, have as an entailment something specified in some other
file)


So we wind up with the following base classes -

	test:PositiveTest
	test:NegativeTest
	test:ParserTest
	test:EntailmentTest

and subclass those pairwise to produce

	test:PositiveParserTest
	(which has one or more test:inputRDFXML properties,
	and one test:parserResult property)

	test:NegativeParserTest
	(which has one or more test:inputRDFXML properties,
	and no outputs (a failure is expected))

	test:PositiveEntailmentTest
	(which has one or more test:input properties,
	and one test:entailment property)

	test:NegativeEntailmentTest
	(which has one or more test:input properties.
	and one test:entailment property - the entailment
	should _not_ hold)

2. Representing input files.

It's easier to draw a picture of this:

	<test:RDFXML>
	  <test:primaryInstantiation rdf:resource="http://www.w3.org/..." />
	  <test:localInstantiation rdf:resource="relative/address/of/tcfile" />
	</test:RDFXML>

generally, something running a test case could go to the web to find its
input; or, optionally, process the local copy of that resource (treating
its base URI as that given by the primaryInstantiation property). We
hang both of these properties off a bNode since we might conceivably
wish to represent multiple renderings (with associated mime types) at
the same URL (ie, the test:RDFXML node in future might get a mimeType
property).

(Note that here, the resources denoting the input files are labeled with
the URIs that can be dereferenced to get the content of those files,
which seems to be a common convention - it's worth pointing out though).

3. Putting everything together

Finally, there are some other properties that might be attached to a
test case (eg, relatedIssue, comment) plus the usual slew of DC bits and
pieces if required. These should be ignored by test-case processing
machinery.


Schema attached (needs a namespace in W3C land) and a sample document.

I'd suggest the format for the manifest follow the example closely
(although rendering it in ntriples instead is an option).

Cheers,
jan


-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
Just because I have nothing to hide doesn't mean I have nothing to fear.