See also: IRC log
http://www.w3.org/WAI/ER/EARL10/WD-EARL10-Guide-20090422
CV: cleaned up first section
... would like to look at "use cases" and "testing process" section
... working on section 3 for the next call
MS: we are defining EARL as a framework in the
abstract
... requirements document catching up
... also, we say not restricted to the Web
... but in the requirements we restrict ourselves
... do we have a mismatch?
SAZ: we restrict ourselves in the requirements,
because we are not chartered to do so
... but we sure hope that EARL is useful outside the Web
... might be simple editorial changes such as adding "may"
MS: could reflect that in the requirements, with a "may" statement
SAZ: agree
[no objections]
MS: some of the sections are long, and we may
want to break them up with sub-headings
... regarding the first use case, I don't understand the relationship to the
different regulations
... could be confused that EARL maps between them
CV: I see your point
SAZ: agree, focus needs to be on languages rather than technical requirement
<scribe> ACTION: Shadi and Michael look into current acronym best practices [recorded in http://www.w3.org/2009/04/29-er-minutes.html#action01]
<trackbot> Created ACTION-89 - And Michael look into current acronym best practices [on Shadi Abou-Zahra - due 2009-05-06].
MS: what about the last use case?
SAZ: title seems to repeat an earlier use case
... and the content goes back to semantic *Web* rather than showing something
not Web related
... if we want to show something outside the Web, how about software quality
assurance?
CV: could use software quality assurance
SAZ: need to make sure that the list does not
seem exclusive
... maybe add a qualifier in the introductory sentence, like "including" or
"such as"
... the last sentence could say something like "other use cases outside Web
quality assurance"
... and have the content provide an example for software quality assurance
CV: would like it to start with a verb like the
others
... do you mean putting this outside the list?
MS: could do it outside the list, as a separate paragraph
[agreement]
MS: the second use case reflects what we can
"aggregation" in the requirements document
... need to come back to that later and compare to what we mean with
"aggregation" in the requirements document
SAZ: another angle of aggregation is inference,
to deduce new results based on the existing data set
... such as "test 1,2,3,4 pass therefore requirement A pass"
... but this needs another layer of a test description logic
... that controls the combinations
... but EARL supports inference
CV: simplified the explanations and figure
SAZ: we have to avoid any direct dependency on a
non open standard
... we seem ok for now but need to beware of this
MS: we are more losely coupled than in previous drafts
CV: regrets for 6 May
SAZ: can work on the requirements next week
... also pointers document
Next meeting Wednesday 6 May, 2009