this is some rough notes by Charles McCN about how to design a testing/reporting tool. Last played with $Date: 2000/09/18 14:32:17 $
I am thinking in terms of implementation via database tables, but this should be expressable in RDF. At least the output should be available as RDF, and the whole design should conform to the RDF model.
A table of elements that can be tested. either an element of an XML language, or a type of tool. This should be of type URI, with some scheme defined for tool types (might as well use this page as the namespace for tool types).
For each element there can be tests that are automatic, or manual. Example of automatic test is whether the element meets the DTD/schema requirements. Manual tests include whether alt text is useful for the thing in question. Use a hash over a document to ensure that it hasn't changed since a test was done. A test can have a description, or a method (e.g. POST the element content to an automated checker, or a description of how to perform the test).
the elements of a particular document can be named as an Xpointer URI - the document itself is assumed to have a URI.
Each test is whether the element conforms to a particular requirement - each requirement is a URI (for example a checkpoint in ATAG)
Need a matrix of tests required for each type of element. For example the appendix of requirements for each HTML element, or the list of tests for an image editor to pass ATAG x.y (with respect to WCAG a.b if applicable)
Need to have a way of saying who has performed a set of tests, when, what is the document hash (is this another part of the when or a seperate thing?)
The test results are expressed as meets, meets-to-a-certain-level, doesn't meet, a particular requirement. The table of tests required covers non-applicability, anything without a result means "not tested".