Questions and proposals related to strawman schema from F2F

Hello,

Nick Gibbins published an earl strawman schema [1] during the F2F in June.  Since we almost have consensus about schema changes (SBP has some objections), I have been using Nick's schema to generate the next draft of an EARL 1.0 spec.  Has everyone had a chance to look at the strawman?  

I compared the strawman to the 1.0 test schema [2].  What follows is a list of classes and properties not defined in the strawman and proposals for how to deal with them (or not). Assuming we move forward with the strawman,  I want to be sure we don't accidentally leave out something important.  

Please let me know if you agree or disagree with any of these proposals.

1. Severity (new)
At the F2F we had consensus that a severity property, similar to confidence and validity, would be a good thing.  I propose we add something to the strawman.  Refer to Ian's proposal: http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2002Jun/0044.html

2. repairInfo, expectedResult, suspectAgainst (from 1.0 test)
These seem to be evaluation-and-repair-tool-specific and don't seem necessary to combine or compare results of tests.  No changes to the strawman proposed.

3.  operator, operatorInstructions, purpose (from 1.0 test)
These describe properties of the testCase.  Since we do not want EARL to be a pseudo-test description language, it makes sense to get rid of these.  One question: what if the operator is different from the assertor?  It seems the two could share the assertion. No changes to the strawman proposed.

4.  testMode (from 1.0 test)
testMode had 3 instances: automatic, heuristic, and manual.  One of the original features of the language was the ability to store information about how the testSubject was evaluated and who made the assertion.    We get at this somewhat with properties of Assertor, but this could be different information than the Assertor properties.  If not covered by Assertor properties, I propose we add something to the strawman. 

5. TestCriteria,  suite, level, excludes (from 1.0 test)
While these describe pieces of the testCase, at the face to face we agreed that we need some way to group tests.  Suite, level, and excludes were created to do this.  I propose we add something to the strawman.  Ideas?  

6. os, version (from 1.0 test)
Is this covered by platform.  It seems to me that these are necessary to uniquely identify user agent test subjects.  If not covered by platform, I propose we add something to the strawman.  

7. snapshot  (from 1.0 test)
I think this was created to help deal with dynamic web content.  A snapshot could capture the content at the time of an evaluation. Is this handled by reprOf?  At this time, no changes proposed.

8. date  (from 1.0 test)
I believe SBP created an EARL-specific date datatype to deal with ambiguities in DC. Date is important in identifying "versions" of dynamic web content.  The strawman does not contain any constraints other than rdfs:range and rdfs:domain, whereas 0.95 and test1.0 had a variety of constraints (mostly daml).  Many folks felt that constraints was something to attempt in a future version after daml/oil/owl/other are stable.  Is creating a datatype for dates a similar issue?  Has this been dealt with someplace else (DC?) since earl:date was created?  I do not have a proposal one way or the other at this time.

I look forward to your comments.  
--wendy

[1] http://www.ecs.soton.ac.uk/~nmg/er-swad/earl-strawman.rdfs
[2] http://www.w3.org/WAI/ER/2002/06/earl1-schema.rdf

-- 
wendy a chisholm
world wide web consortium 
web accessibility initiative
seattle, wa usa
/--

Received on Wednesday, 21 August 2002 17:35:11 UTC