Re: Editor's draft comments

Hi,

Carlos Iglesias wrote:
>>> * 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.
> 
> Then you will be defining foaf:Organization as a compound 
> assertor in an implicit way, I think we should stay considering 
> Organization as a kind of single assertor and then the problem 
> remains, otherwise (if we allow Organization to be a compound 
> assertor) this could bring us new issues with the definition of 
> compound assertors.

So let's say a Single Assertor class refers to a foaf:Organisation. No 
Compound Assertor anywhere. What testing mode would you use?

Is this a wording issue where "combination of persons and software 
tools" is causing confusion with the definition of the Compound Assertor 
class?


>>> * 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). 
> 
> Ok, forget all the mess I made about classes. What I mean 
> is, shouldn't we also move TestMode to an Assertion sub-
> section (2.1.1) to be consistent?

Then we should also move Assertor to 2.1.2, Test Subject to 2.1.3 and so 
on. There is no difference between earl:Assertor and earl:TestMode when 
it comes to the schema.


>>> * 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.
> 
> Why not?
> I think this information it's relevant for the correct usage 
> of the Assertion class as it has considerable influence in the 
> support of aggregation of test results (Requirement F04 for 
> EARL) and could go unnoticed in this section.

I think the text talks more about the usage of EARL (its design model) 
rather than the usage of the assertion class itself (though this is the 
basic building block of EARL reports). I don't feel strongly, I just 
prefer not to have it there. Let's see what the other say.


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 19:14:49 UTC