Re: Test cases: format of input and output

Jan Grant wrote:
> 
> 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")

generally: make it available via HTTP and give
it the relevant license and availability/persistence.

Sending stuff to this list grants the relevant license
(as a consequence of the agreement folks executed
when they joined the group; see the charter and
W3C process for details).

I'd like to say that it assures the relevant
persistence, but actually, our list archives have
been known to reshuffle the numbers occasionally. Sigh.

So... sending stuff as attachments to this list
should be sufficient, but I don't think it's strictly
necessary; there are perhaps other ways to meet
the above constraints.

> 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.)

Yikes! optional behaviour? I should hope not; I should
hope each RDF document means exactly one thing. But I guess
we'll figure that out as we go...

> 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?).

We have avoided "deprecated" so far (whew!); let's keep it that
way as long as we can...


I have some comments on the format itself; I think I'll
send those separately...


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Friday, 25 May 2001 14:59:38 UTC