Re: Editor's draft comments

Hi Carlos,

Thanks for your comments, please find some responses below:


Carlos Iglesias wrote:
> * 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"/>
> </earl:compoundAssertor>
> 
> Should we add something else in the prose to prevent this misuse of a Compound Assertor? 

How about "A Compound Assertor is a group of two or more persons and/or 
software..." or something simple along those lines. Anything else more 
elaborate could make the section more complex and confusing, and there 
seems to be little incentive for misusing the Compound Assertor in the 
first place.


> * 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. 

Firstly, I think the date property in the Test Subject class must be 
used to describe the test subject itself. In other words, it should not 
be used to describe the testing date. If we need a "testing date" then 
we should either put it directly in the Test Result class (recommended) 
as part of the description of the result, or in the Assertion class.

As to the other two options, the date is dependent on the nature of the 
test subject and I doubt we can easily find consensus on its meaning. So 
instead of trying to define the usage of the date property in the Test 
Subject class, I propose we specify the usage of the (inherited) date 
property in the Content class. This date should either be the creation 
date if available (for example if the HTTP server provides this header), 
or the identification date otherwise.

What do others think?


> * 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)

I agree. Any objections?


> * 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.

No, it could be a foaf:Organisation too. Actually, I think this was the 
original use case for the "mixed" value.


> * 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?

Not sure if this belongs here, I think it is better placed in the 
"Pointer Methods in RDF" document. At this stage, the term "equivalent 
pointers" may not be familiar to the reader.


> --- 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).

No, please don't open up this can of worms! ;)


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

I will take another editorial pass at this section, and try to reflect 
your comments regarding consistency.


> * 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?

Test Mode is actually a class, just a very simple one of fixed values. 
Outcome is also a class, which is why it also has a sub-section (only at 
a different node in the hierarchy).


> * 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. 

Agreed.


> * 2.6 Test Result
> 
> "A Test Result should also include instances _of_ the following..."
> 
> The _of_ is missing

Thanks.


> * 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]

Well actually an encoding algorithm must be applied to any content, not 
only HTML. I'll take a stab at this...


> * Example 12
> 
> "_An_ (not "The") HTML page from..."

Thanks.


> * 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?

I don't think so.

> Also I'd prefer the use of just "test" instead of the expression "single test" to avoid the identification with "atomic test"

OK, agreed.


Regards,
   Shadi


-- 
Shadi Abou-Zahra     Web Accessibility Specialist for Europe |
Chair & Staff Contact for the Evaluation and Repair Tools WG |
World Wide Web Consortium (W3C)           http://www.w3.org/ |
Web Accessibility Initiative (WAI),   http://www.w3.org/WAI/ |
WAI-TIES Project,                http://www.w3.org/WAI/TIES/ |
Evaluation and Repair Tools WG,    http://www.w3.org/WAI/ER/ |
2004, Route des Lucioles - 06560,  Sophia-Antipolis - France |
Voice: +33(0)4 92 38 50 64          Fax: +33(0)4 92 38 78 22 |

Received on Monday, 12 March 2007 17:23:03 UTC