RE: Editor's draft comments

Hi Shadi,

Let's go for another round:

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

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)
 
> Is this a wording issue where "combination of persons and 
> software tools" is causing confusion with the definition of 
> the Compound Assertor class?

I think this is becoming a can of worms as we are opening several issues regarding Assertors.

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?

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

* Semiauto: Can be only compound by definition,

main Assertor --> Software
secondary Assertor --> at least one Person and/or Organization, whatever else

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

* Heuristic: ¿¿¿???

single or compound but just Software?
single or compound with whatever main and secondary Assertors?

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

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


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

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"

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


Regards, 
 CI.
 
--------------------------------------

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 Tuesday, 13 March 2007 16:38:35 UTC