Re: Editor's draft comments

Hi Carlos,

Carlos Iglesias wrote:
> Hi Shadi,
> 
> Let's go for another round:

:) I'm getting dizzy ;)


>> So let's say a Single Assertor class refers to a 
>> foaf:Organisation. No Compound Assertor anywhere. What 
>> testing mode would you use?
> 
> If we think that an Organisation is a compound Assertor and that it may also include Software (I'm not in favour of the last one) could be also manual, heuristic or mixed, otherwise it could be just manual or heuristic (see next for explanations)

I think you are mixing up how single/compound assertors were defined. A 
Single Assertor is a single entity. This could be a group of /things/ 
(as defined by foaf:Group) or a whole organisation (as defined by foaf). 
In other words, a Single Assertor does not have to be one single tool or 
one single person but rather one single *entity*.


> My point of view so far is:
> 
> * Manual: Can be single or compound, 
> 
> Single --> just Persons and/or Organizations.
> Compound --> main: Persons and/or Organizations; secondary: whatever
> 
> Problems --> Compound assertor without mainAssertor: a group of volunteers that carried out a test throught an NGO website, who's the mainAssertor?

Since all volunteers contributed equally, they are all mainAssertors.


> * Automatic: Can be single or compound, but just Software
> 
> Problems --> Compound assertor without mainAssertor: we use a couple of Web accessibility checkers simultaneously to contrast results as recommended by WCAG, what tool is the mainAssertor?

Again, they could be all mainAssertors if there is no "leader tool".


> * Semiauto: Can be only compound by definition,
> 
> main Assertor --> Software
> secondary Assertor --> at least one Person and/or Organization, whatever else

Wrong assumption, it *should* be compound. However, the user behind a 
semi-automated tool may not be disclosed in the report. The tool could 
be a Single Assertor but the mode of testing was semi-automatic.


> * Mixed: Can be only compound (and must include Persons, or Organizations, AND Software),
> 
> main Assertor --> whatever;
> secondary Assertor --> whatever 
> 
> Problems --> If there is no detailed information by definition, how could I know who or what is the mainAssertor?

As discussed above, mixed does not imply a Compound Assertor. A Single 
Assertor could (by definition) be a whole organisation as one single 
entity. How this single entity carried out the testing is actually a 
separate question.


> * Heuristic: żżż???
> 
> single or compound but just Software?
> single or compound with whatever main and secondary Assertors?

Let your imagination fly! For example a tool takes input from humans and 
"guesses" new result. This *could* be described by using the compound 
class with the tool as the main assertor, and the humanoids as the help 
assertors. This is one of many possibilities and scenarios.


> Note that the problems mainly come from the requirement of a mainAssertor for compound Assertors, but we need the mainAssertor distinction for manual and semiauto modes

I think the problem comes from tying the test mode too closely with the 
assertor. Of course they are related but not married. The test mode is 
actually there to help clarify what the assertor did, this is not always 
apparent from the mere structure of the assertor class.


> * Additional question:
> 
> - Should we define Organization as a type of Compound Assertor not as a single one? After all, an Organization is a group of people and other resources (software included?), isn't it?

It is a *single entity*. Do you have suggestions on how I can improve 
the wording to clarify this meaning?


>> 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.
> 
> Maybe we should, and then we'll transmit a clear idea of the hierarchy in EARL with just the Table of contents.
> There's also no difference between earl:TestResult and earl:Outcome when it comes to the schema nor between earl:Single/CompoundAssertor and earl:Assertor, but they are sub-sections. Additionally I'm not talking about the schema now, I'm talking about the document hierarchy.
> 
> IMO the most important think is to be consistent (and so, easy to predict) following always a previously established criterion. Some random criteria that could make sense are:
> 
> - Use always a section per Class
> - Use subsections just for sub-classes
> - Use subsections to reflect EARL hyerarchy
> ...
> 
> I think we're not currently following any of the previous, are we following any other?
> Maybe it's not the most important thing right know, so I can live with it as is, but I think it may be a good improvement if we think as EARL "outsiders"

This is editorial preference and shouldn't stop us from moving to Last 
Call, let's see what others think about it.


>>>>> * 3 Conformance
>>>>>
>>>> [...]
>>> 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.
> 
> What you say also makes sense. Still think that this information is relevant in the Assertion section but can live with it as is if nobody else think the same.

Also editorial preference, I think.


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 Wednesday, 14 March 2007 00:32:32 UTC