Re: Evidence Class

Hi,

Charles McCathieNevile wrote:
> Can you elaborate on what complications you think we will be opening  
> ourselves to? Obviously there is no single agreed rules language for 
> RDF,  so interoperability depends on being able to understand the things 
> pointed  to. But in many cases the rules are going to be simple OWL, I 
> believe -  simple enough that we could describe it in the spec.

My specific concerns are scope creeping (some issues may be even out of our charter):

* Will we develop our own rules language?
* Will we start defining WCAG interpretations?
* Will we extend the test case description markup?


> The minutes of the call state " ruleSet is a can of worms which could 
> be  scary for us to introduce " yet provide zero evidence to support 
> the  statement. If this is something more than mere FUD, please 
> elaborate,  since it appears that the meeting almost decided (there is 
> no decision  recorded, so I can only assue that one has not been taken 
> yet) to remove a  property without testing the use case based on this 
> single unsupported  (except by repetition) statement.

FYI, we did do a mini "round the room" to get a feel for where people were at but did not identify a resolutions due to the absence of participants (including the proposer of this class, you).

Please find more elaboration on my concerns above. I am not really understanding what added value the earl:ruleSet would have that is not already implied by the earl:TestCase. Can you please elaborate on a specific use case and preferably by practical example?


> The evidence construct does not remove the need for test mode. It 
> applies  in cases where the test mode is by inference (whose URI happens 
> to end in  heuristic - proof that relying on URI strings to be 
> meaningful is a dumb  idea ;-), but would point to tests done manually 
> or automatically.

I think, the currently proposed earl:TestMode becomes redundant in the light of the new earl:Assertor and earl:Evidence classes (together). A tool can infer how a test was made much more precisely by analyzing these classes. For example, a tool can infer that a test was not done fully automatically or fully manually but semi-automatically because the person was using a tool. Also the earl:Evidence class may propose cascades of related assertions that were tested in different modes. How tool process this may be different that what earl:TestMode suggests.

Anyway, this slightly off topic and maybe even premature to discuss right now. Let's revisit earl:TestMode once we have a more stable earl:Evidence in place and see what added value it brings (or not).


> Indeed, I would expect some of the rules used (basic OWL constructs,  
> mostly reusing things we already have in the current spec draft) to  
> actually discuss test mode - for example a restriction on WCAG 1.1 
> results  that only trusts manual verification for a pass, but is 
> prepared to accept  automatic verification for a fail, seems an obvious 
> thing to do.

This seems to me like a different project outside the scope of the EARL Requirements. It implies proposing a rules language (even if just basic OWL constraints that may or may not be the right language for expressing these restrictions) as well as defining an interpretation for WCAG. Am I missing something here?


> I think it makes sense to make it a property of the Assertion, since 
> that  is where the test mode property goes...

It makes sense to me too.


Regards,
  Shadi


-- 
Shadi Abou-Zahra,     Web Accessibility Specialist for Europe 
Chair and Team 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 Monday, 26 September 2005 09:29:42 UTC