RE: validity levels

Hi group,
 
> As to the 'extended values' which we are currently talking 
> about, there have been a couple of proposals to address 
> these. Here are the current proposals for discussion:
> 
> 1. provide the 'extended values' as subclasses of the 'core values' 
> within the EARL namespace (thus described in the EARL 1.0 
> Schema); 

I think it's the best option in terms of interoperability but, which subclasses are we going to define?

ConditionalPass?
AlmostPass?
NotSureIfPassOrNot?
PassWithMinorIssues?
PassByTheSkinOfOne'sTeeth?
...

Seriously, as said before there almost as many interpretations of "warning" as number of tools. If the idea is something like:

earl:WarningPass
earl:WarningFail
earl:WarningCannotTell
...

Then maybe could be better just an additional earl:warning property for the TestResult class

> 2. provide the 'extended values' as subclasses of 
> the 'core values' but in a different namespace (to be 
> described in the EARL 1.0 Guide);

I don't see any benefit in this approach. If we want EARL reports to be interoperable, tools will need to be aware and understand this values, so I think it'd be better the 1st option (they need to be in the core language), but I don't think it's a good option (see comments before :o)

> 3. do nothing and encourage 
> tool developers to create, publish, and maintain the RDFS 
> about their subclasses of the 'core values';

This is the one I prefer but with a shading of meaning, I think it should be: do nothing, end of the story.
I mean, if we encourage tool developers to create, publish and maintain the RDFS with their subclasses then we should also encourage tool developers to support and interpret others subclasses (if we want EARL reports to be interoperable on the Validity Level) and that's too much additional work for tool developer.
IMO Validity Levels are one of the most important/widely implemented/most interoperable characteristics of EARL, so I don't like the idea of playing with it too much (without any really important reason).

> Note that, as CarlosI pointed out, the dc:description can 
> also be a valuable mechanism for conveying information to the 
> end-user. However, these would be text-based messages and not 
> values that tools can pick up and work with. This should be 
> therfore in addition to one of the subclassing approaches 
> listed above.

Note that, even if we create new subclasses, the warning itself will remain as a text-based message (and not values that tools can pick up and work with), won't it? The tools could be aware that there's something "strange" there (a warning) but that's all they get. Something like: 

Hey! There's a warning over there and it means: "text-based message"

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 Wednesday, 25 October 2006 09:45:30 UTC