Re: earl message

On Tue, 26 Apr 2005 05:59:20 +0200, Nils Ulltveit-Moe <nils@u-moe.no>  
wrote:

> Hi Charles,
>
> Since EARL never formally reached an accepted 1.0 state, but several
> companies has used is as such, we may have to live with these
> inconsistencies for some time.

I'll have a look around to see how many things I have published (earl by  
example, and the EARL output of Hera are two I know of already) or can  
find that implement earl:message as a property of the assertion and not of  
the result. And how many do it correctly.

For a draftproperty in an intermediate namespace that should be OK. But we  
should figure out were we really want it and get it right in the final  
thing. Which leads to a discussion of versioning terms, which leads us to  
the Best Pracices group where they are working on this. Timefora new  
thread on that...

meanwhile

> I am not sure, though, that the message should be a property of the
> Assertion, since the assertion should be quite general and defined by
> e.g. a WCAG checkpoint. An implementation of that checkpoint is probably
> far more fine-grained than the checkpoint itself, and the message may be
> used to convey more information about why the test took the decision it
> took.

No, the assertion is defined as being about the result of a particular  
test (the testcase), which can be as fine-grained as checking the quote  
types in the XML Processing Instruction i the first line of XML documents,  
or as coarse-grained as "this is accessible" where someone defines a URI  
that means that, or "this meets WCAG triple-A" (which is effectively the  
level of specificity in current claims made using the WAI logo - in many  
cases there isn't just a lack of information about what tests were done,  
but it is clear that it is not an assertion based on detailed information).

I am ambivalent about where the message belongs. If we are going to permit  
multiple results (for example for complex tools which offer probabilistic  
assessments) then it should almost definitely be on the result. Or at  
least be able to be on the result, which is different.

So the choice seems to come down to

  1 relaxing the constraint on the domain to cover the assertion or result,  
or
  2 deciding that there won't ever be multiple test results and that it  
makes sense to only have the message on the Assertion, or
  3 keeping it restricted to result and declare that some current work is  
in error (it is) and should be fixed (what I am trying to sneak out of,  
but maybe not entirely without reason).

cheers

Chaals

-- 
Charles McCathieNevile                      Fundacion Sidar
charles@sidar.org   +61 409 134 136    http://www.sidar.org

Received on Tuesday, 26 April 2005 17:18:21 UTC