W3C home > Mailing lists > Public > public-wai-ert@w3.org > March 2007

Editor's draft comments

From: Carlos Iglesias <carlos.iglesias@fundacionctic.org>
Date: Mon, 12 Mar 2007 17:19:37 +0100
Message-ID: <09700B613C4DD84FA9F2FEA52188281901E7DCF7@ayalga.fundacionctic.org>
To: <public-wai-ert@w3.org>

Hi everybody

Some comments and thoughts about EARL last editor's draft [1].

* 2.2.2 Compound Assertor

"A Compound Assertor is a group of persons and/or software that are responsible for making an assertion. _Each group must have at least one primary Assertor_ identified by the earl:mainAssertor property, and _may have secondary Assertor_ identified by the earl:helpAssertor property..."

Only one primary Assertor (that could be a single Assertor) is required, so as currently defined the following is a valid Compound Assertor:

<earl:compoundAssertor rdf:about="#assertor">
  <dc:title xml:lang="en">Bob using Cool Tool</dc:title>
  <dc:description xml:lang="en">Bob doing some testing</dc:description>
  <earl:mainAssertor rdf:resource="#bob"/>

Should we add something else in the prose to prevent this misuse of a Compound Assertor? 

* 2.3 Test Subject

"dc:date: Date on which the subject was tested (or when it was identified if more appropiate)"

There is no clear indication about when to use each of the two kind of dates that are propossed, this makes difficult to know what to expect from the dc:date property.

IMO there are 3 dates that are relevant for EARL:

- Testing date: the date when the test wan run. It should be a property of the Test Result, as it's the date when we got this result.
- Creation date: the date when the resource was created. It's a property of the Test Subject but it's not easy to know.
- Identification date: the date when the resource was fetched to run the test. It's a property of the Test Subject and we can always know it.

As the creation date of the resource is the less relevant for our use case, my proposal is using dc:date on Test Subject for the date on which the subject was identified (fetched), and use dc:date on Test Result for the date on which the result was obtained (the test was run). Also note that identification date and testing date may be the same in several cases. 

* 2.4 Test Criterion

In order to benefit interoperability, shouldn't we add a note to encourage people to use the "common accepted references" for test criteria when they're avalaible? (e.g WCAG URIs)

* 2.5 Test Mode

"mixed: Where a combination of persons and software tools was used to carry out the test, but there is no detailed information about the primary responsibility for determining the outcome of the test. This includes when testing is carried out by organizations or groups of assertors, and the exact testing process is not disclosed."

It must be a compound assertor by definition, then we need a mainAssertor (required for compound assertors) but in this case it's impossible as the primary responsability is unknow.

* 2.6 Test Result

In order to benefit interoperability, shouldn't we add a note to encourage people to use as many equivalent pointers as possible?

--- Other editorial comments ---

* 2.4 Test Criterion

There are several inconsistences in the usage of "Test Criterion" and "Testable" terms all around the section. The easiest way to fix the problem may be to call the class TestCriterion intead of Testable, this way we'll be also consistent with the rest of the document (using the same name for the class and the section of the document).

I think also that the TestRequirement is not well represented in the prose of the section in favour of TestCase.

Proposed wording:

A Test Criterion is a testable statement, usually one that can be passed or failed. It is a super class for all types of criteria including things such as validation requirements, code test cases, checkpoints from guidelines such as Web Content Accessibility Guidelines 1.0 [WCAG10], or others.

While the generic earl:TestCriterion class can be used directly, one of the following types should be used:

    A <strong>higher-level requirement</strong> that could be tested by executing one or more sub-tests. For example WCAG 1.0 Checkpoint 1.1 which is tested by executing several sub-tests and combining the results
    A <strong>test</strong>, usually one that is a partial test for a requirement. For example, checking if an image has an alt attribute which could be part of testing WCAG 1.0 Checkpoint 1.1.

A Test Criterion may be a single criterion, or part of a compound criterion. These relations may be described using Dublin Core's dct:hasPart or dct:isPartOf properties. Additionally, a title or description for the Test Criterion may be included by using the Dublin Core dc:title or dc:description properties.

* 2.5 Test Mode

Is the only property that has its own section in the document. Should this information be included in the Assertion class section as we did with the Outcome?

* 2.5 Test Mode

"semiauto: Where a software tool was primarily responsible for generating a result, _even if with some human assistance_. This should be additionally noted through the earl:compoundAssertor class of the Assertor."

May be: "Where a software tool was primarily responsible for generating a result (mainAssertor) _but with some human assistance_ (helpAssertor). This should be additionally noted through the earl:compoundAssertor class of the Assertor."

To clearly state that the human assistance can't be optional, otherwise it's not a semiauto mode. 

* 2.6 Test Result

"A Test Result should also include instances _of_ the following..."

The _of_ is missing

* 2.8 Content

As the sourceCopy in HTML Content is the HTTP body content, Shouldn't we at least refer to the same algorythm we use for HTTP in RDF? [2]

* Example 12

"_An_ (not "The") HTML page from..."

* 3 Conformance

"...Each assertion contains information about a single test that was carried out. EARL does not prescribe how to group tests into a report since this is highly application and end-user specific. For example, reports generated for Web developers may contain more detailed results in order to repair bugs while reports generated for project managers may contain aggregated results with less detail on the specific issues..."

Shouldn't this information be in the Assertion section as a note?
Also I'd prefer the use of just "test" instead of the expression "single test" to avoid the identification with "atomic test"

[1] - [http://www.w3.org/WAI/ER/EARL10/WD-EARL10-Schema-20070226]
[2] - [http://www.w3.org/WAI/ER/HTTP/WD-HTTP-in-RDF-20070301#body]


Carlos Iglesias

CTIC Foundation
Science and Technology Park of Gijón
33203 - Gijón, Asturias, Spain 

phone: +34 984291212
fax: +34 984390612
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org
Received on Monday, 12 March 2007 16:19:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:55 UTC