- From: Carlos Iglesias <carlos.iglesias@fundacionctic.org>
- Date: Mon, 23 Oct 2006 19:00:30 +0200
- To: "Charles McCathieNevile" <chaals@opera.com>, "Johannes Koch" <johannes.koch@fit.fraunhofer.de>, "ERT group" <public-wai-ert@w3.org>
> >> I think these tools are misused, some users assume they can measure > >> compliance, this means 'warning' equals 'pass'. Scary! > > > > That's right. So don't call it warning. > > Well, sometimes the warning is that you could do better. > Sometimes it is > something that the test cannot determine. Etc. But everytime it should be one of: pass, fail, cannotTell, notApplicable or notTested. As said before, every tool define "warnings" it's own way. IMO every use case of "warning" is easy to accommodate in one of the EARL validity levels. Then you can use the dc:description within the earl:result to store the warning message itself. After all, are warnings anything else than end-user messages? > > But I still see the need for interoperably subclassing the > "standard" > > validity levels. > > Sure. To be interoperable you have two options. Require consuming > technology to understand RDFS sub-properties and classes, or > add both > properties. To add both properties, I think you have two > kinds of result, > which I believe is not what we allow currently. (I am not > sure what the > logic boffins came up with about whether a result that is > duplicated by a > subClass of itself is a different kind of result, but that seems > intuitively likely...) Obviously the validity of the test result is a key part of EARL reports, and I don't like the idea of "forcing" tools to understand EARL extensions (validity subclasses) to be EARL-compatible. 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 Monday, 23 October 2006 17:00:58 UTC