Evaluation and Repair Tools Working Group Teleconference

Requirements Document

<shadi> http://www.w3.org/WAI/ER/EARL10/WD-EARL10-Requirements-20090421.html

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2009Apr/0026.html

ah, ok

points from MS on requirements document

0 is requirement doc for entire EARL document suite or just schema?

SAZ: assumption seems to be applies to the EARL Schema only but not called out explicitly

CI: it seems implicit that these are reqiurements for the schema
... but still, ambiguity between EARL - Schema vs. entire suite of documents

SAZ: document is dated, developed in 2005 prior to splitting EARL into modules or parts
... good place to define EARL and its related components or vocabularies
... return to overview doc and adapt accordingly

CI: requirements doc is not the place to define relationships between vocabularies

SAZ: requirements doc does not need to spell out in detail but is there a problem with pointing out or specifying each vocabulary/component?

CI: entire thrust of document must change - title, for example, should be something like "Requirements for EARL Framework"

SAZ: if 'EARL 1.0' is spelled out as a framework with many parts, then thrust of requirements doc is clear

CI: agreed - specify as a framework but specifics about components should not be a requirement (e.g. number of vocabularies, relationship between them)

JK: agree with CI - requirements document (RD) should be a document pertaining to the entire suite
... what is the purpose of the requirements document?

SAZ: 1) internally, for the group, keeps us on track in temrs of what we're trying to do
... 2) people do read to understand the goals
... 3) demonstrate that we've satisified our requirements to W3C community

JK: a bit odd, though, to write/tinker the RD after the suite is nearly complete
... could have RD for each vocabulary
... overall framework RD and specific RDs for each vocabulary (Pointers in RDF, Representing Content in RDF, etc.)

SAZ: clearly an iterative process, started in 2005
... adjust and adapt as we move ahead
... requirements is not as stringent as, say, in a software development context
... good example of need in external context is points made by XML group about Pointers in RDF; might ahve been answered by a solid RD
... conclusion seems to be that RD is for entire EARL suite

RESOLUTION: Requirements Document has scope of entire EARL Document Suite, not just Schema and should be spelled out explicitly in RD

SAZ: resolution may have implications for title, structure, and other aspects of the RD
... MS should edit abstract according to more generic use of EARL to non-accessibility realms
... restriction to web is necessary given area of expertees but want to remain open to toher ocntexts
... avoid scope creep and entering into

MS: Removed "computational" from D03 but do we need to have "in a reasonable time?"

SAZ: need some sor tof formulation about reasonable performance for EARL consumers and producers based on complexity of the specification
... persistence in F03 refers to repeatability given, say, http exchange
... F04 is supported via extensibility; somewhat handled by the guide

<shadi> http://www.w3.org/WAI/ER/EARL10/WD-EARL10-Schema-20090410#TestSubject

JK: aggregation seems to mean colection or assimilation
... if not the meaning, change the word
... one interpretation is when a test subject is tested against different test criteria (e.g. WCAG2, Sec 508)

CV: combine test results from testing same resource

SAZ: recall discussion of a truth table for aggregation (e.g. what happens if one test result against a test subject is PASS and another result of same resource is FAIL)

ok

SAZ: Question is how do we "support aggregation?

"...no guidance on resolving conflicting results

scribe: MS should start a thread on this

JK: logical combination of composition of test results is out of scope for EARL

Pointer Comments

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2009Apr/0028.html

SAZ: propose to find a different name for ptr:XMLNamespace given that terms prefixed with 'xml' are reserved
... look at introduction and abstract for more clear description of text-orientedpointers

<carlosI> rememeber that we have also the XML names problem in other documents like "Representing Content in RDF"

SAZ: remove examples that refer to abstract or generic classes

EARL 1.0 Guide Document

<shadi> http://www.w3.org/WAI/ER/EARL10/WD-EARL10-Guide-20090422.html

Next meetings

<shadi> 29 April 2009