Evaluation and Repair Tools Working Group Teleconference

31 Aug 2011


See also: IRC log


Shadi, Emmanuelle, Philip, Samuel, Kostas, Christophe


Continue processing comments


PA: comment makes sense

SAZ: let's look one by one




SAZ: comment not really precise -- EARL 1.0 requires an identfying name which could be dc:title, foaf:name, or doap:name
... any issues with that requirement?


scribe: description is not required though, because it may not be known
... same for TestSubject
... maybe could say "one identifier" rather than "identifying name/title"?

PA: conformance section looks clearer than in the comment

RESOLUTION: change "identifying name/title" to "identifyer" in conformance requirements 2.a, 3.a, and 4.a


SAZ: requirement is dc:date and earl:outcome (which in turn must have an identifyer and a description)
... additional information is only optional
... ok?

KV: agree

SS: agree

EG: don't see why we need consistency


SAZ: provide pre-defined values for test mode
... if you define your own then you need to describe them
... for example, if a vendor uses foo:heuristic, they would need to disambiguiate it
... title would be "heuristic" but also need a description of what that means

<sinarmaya> yes

RESOLUTION: conistency does not make sense because every case has its own justification; some improvement of the wording will be made

<sinarmaya> yes



KV: it is clear, not sure what is requested

SAZ: TestRequirement is broader than "test suite"
... could use TestRequirement to refer to test suites or other compound tests that are not necessarily test suites
... or introduce "earl:TestSuite"

SS: test suite could contain a set of unrelated tests, while a test requirment is a set of related tests

<sinarmaya> uhmmm

SAZ: add test suite or not?

KV: maybe good to include because informative about what TestRequirement and TestSuite is

EG: can be a good idea because can be more flexible

RESOLUTION: introduce earl:TestSuite to mean a series of (related or unrelated) test cases

PA: TestRequirement can still be a combination of TestSuites and TestCases, right?

SAZ: yes, it is more generic

<cstrobbe> Sounds good to me.





SAZ: OutcomeValue is likely to have gradients so proposed sub-classes
... TestMode may not need the same level of specifity

KV: why these gradients?

SAZ: to maximize query-ability

KV: don't think we need it

(keep current approach)

CS: could keep it

<philipA> +1

RESOLUTION: keep as is because no use-cases are known for further subclasses of TestMode

Upcoming meeting schedule

SS: regrets for next week

[next meeting on 7th september]

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/08/31 13:54:49 $