Test cases: format of input and output

OK, basically it seems that we ought to do the following  (DanC?)

For each test case (in the form of a piece of RDF)...

1. Create serialised RDF as an attachment ("test1.rdf")
2. Create expected output (more below) as an attachment ("test1.out")
these come in pairs.
3. Where we've got optional behaviour (x MAY do y) provide enumerated
outputs (test1a.out, etc.)

Expected output should be a list of triples that describe the expected
output (in the following format) OR just "error" to indicate that the
test case is an example of something that should be non-conforming (or
deprecated?).

A triple is represented as:

triple(S, P, O)

where S, P, O are any of:

	r("URI")
	a("ID")
	l("literal")

(with the usual rules about placement of literals). r("URI") is a normal
resource. l("literal") is a literal; a("ID") is an anonymous resource,
which I think (with an eye on the future) that we ought to make
explicitly different from r("#genid").

Something conforms wrt the test case iff it interprets the RDF as
producing* a set of triples identical with the sample output, up to
reordering and the global renaming of anonymous resources.

Re: anon resources - two elements a(X) and a(Y) should be considered to
represent "the same anon resource" iff X=Y (lexically) - and the scope
of the identity of an anon resource is the single test output
attachment.

Clear as mud of course - any real objections?

Once I've had the nod, I'll submit the empty element proposal in that
format (or even beforehand as an example if people prefer).

jan

* for the usual values of "producing" - implying, representing, etc.

-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
Goedel would be proud - I'm both inconsistent _and_ incomplete.

Received on Friday, 25 May 2001 11:17:15 UTC