W3C home > Mailing lists > Public > public-wai-ert@w3.org > March 2007

Re: FYI: Using EARL for Validator Web Service Format

From: Shadi Abou-Zahra <shadi@w3.org>
Date: Thu, 08 Mar 2007 08:42:34 +0100
Message-ID: <45EFBE6A.3060000@w3.org>
To: olivier Thereaux <ot@w3.org>
Cc: www-validator Community <www-validator@w3.org>, public-wai-ert@w3.org

Hi Olivier,

olivier Thereaux wrote:
> You're not saying "reference implementation" in the sense of [1], are you?
> [1] http://en.wikipedia.org/wiki/Reference_implementation

Okay, maybe the word "reference" is a little too much (or a matter of 
definition). I mean an implementation in the sense of the W3C Process 
Document ("independent and interoperable implementation"):
  - <http://www.w3.org/2005/10/Process-20051014/tr.html#cfi>


>> You may be interested in our "Pointer Methods in RDF" document. It is 
>> a *very* early draft and still quite rough but it shows the basic 
>> principle of pointers to point into the test subject from the result 
>> (for example to point to an element that caused the validation error):
>>  - <http://www.w3.org/WAI/ER/Pointers/WD-Pointers-20070222>
> 
> Yes, this looks interesting indeed.
> http://www.w3.org/WAI/ER/Pointers/WD-Pointers-20070222#use-cases looks 
> like it covers most of what would be needed. pointer:linecharlength is 
> useful, so is pointer:selector. Would it perhaps be possible to have a 
> property for "any kind of context", or would that be too vague and hard 
> to use?

I don't understand what you mean by "any kind of context". We have a 
generic pointer class that could be subclassed to define additional 
types of pointers. We will also be adding a "target" or "reference" of 
the pointer in the next revision. Not sure if this is the direction you 
are thinking of...


> I think I understand. It makes sense and it is in a way stricter than 
> what the CSS validator is usually doing. For instance, if you give the 
> CSS validator an HTML page to analyse, it will report conformance issues 
> with the whole, the HTML document and the CSS stylesheets it links to, 
> whereas strictly speaking, if the HTML document does not have any style 
> element or attr, it is irrelevant to CSS conformance. After that, the 
> matter is presenting results to the user.

Yes, the *test case* defines the test subject. It is a tricky thing 
because test cases are often not as atomic as they ideally should be.


> or even, if I don't need to pass a copy of the content and HTTP context 
> (thanks for that! it will be useful to us I'm sure) the following would 
> be ok too.
> 
> <earl:Assertion rdf:about="#assertion">
>   <earl:subject rdf:resource="urn:md5:..."/>
> </earl:Assertion>
> 
> Is that correct?

While this could work, I would personally not recommend it because it 
gives the reader of the EARL report no clue as to what the subject is. 
If you are talking about some sort of content, consider *describing it* 
using the earl:Content class:

<earl:Assertion rdf:about="#assertion">
   <earl:subject rdf:resource="#subject"/>
</earl:Assertion>

<earl:Content rdf:about="#subject">
   <!--// no earl:sourceCopy, it is an optional property //-->
   <earl:context rdf:resource="#urn:md5:..."/>
   <!--// machine-readable context can be compared across tools //-->
   <dc:title>...</dc:title>
   <dc:description>...</dc:description>
   <dc:date>...</dc:date>
   <!--// these properties are for human-readers at some point //-->
</earl:Content>

If you are not actually describing content (or software) then you can 
use the generic earl:TestSubject class directly or subclass it to your 
liking. However, I think for the validator you will be usually talking 
about content in some form.


>> We would be very interested in hearing about your experience with 
>> EARL, and if you spot any issues. Especially when we go for Last Call 
>> later this month, your review comments would be very important to us. 
>> I'll ping the groups here once we are so far...
> 
> I think the next step, as far as the validators are concerned, is to 
> take the existing EARL outputs [2] [3] and update them to use the latest 
> schema, see how much we can put in, what's relevant to validators and 
> what is not.
> 
> [2] http://dev.w3.org/cvsweb/validator/share/templates/en_US/earl_n3.tmpl
> [3] http://dev.w3.org/cvsweb/validator/share/templates/en_US/earl_xml.tmpl
> 
> Anyone on the mailing-list interested in taking this on? This could be 
> an interesting little project, and would not involve coding, only 
> understanding the templating syntax, which is simple.

Unless someone else wants to do an interim update, I will gladly take 
this action item when we pass LC and reach CR stage.



-- 
Shadi Abou-Zahra     Web Accessibility Specialist for Europe |
Chair & Staff 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 Thursday, 8 March 2007 07:43:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:28 GMT