EARL structure and processing model

Hi all,

Based on the discussions in several threads, it seems there are two distinct but not separate topics: the structure of EARL, and the processing model for tools. In the following, I will try to explain these two in more detail.


* EARL Structure
There are several Classes and Attributes in EARL, some of them already exist in the current draft, other may need to be defined. These are some of the entities which have been discussed recently:

- Subject
Currently, the Subject is basically a URL of the page but it is imaginable to also use XPath in order to allow more granularity. A URL would be a fallback (that is compatible with XPath) in case the document does not support XPath (tag soup or non-markup document). More about when a tool should output what is described in the processing model.

- Location
Many tool developers already added such a construct into the EARL their tools output. Indeed, such a construct is needed if the Subject remains coarse as it currently is. However, it makes more sense to try and tie the "location" aspect directly into the subject, for example by using XPath.

- TestCase
Currently, the TestCase is a URI to a test (the test itself doesn't have to be published though, it is just a unique name to identify a test). Often a TestCase may be composed of several sub-tests (for example the TestCase "WCAG-AA conformance" requires numerous sub-tests). It is important that EARL addresses this hierarchy in some form.

- Evidence
Has been proposed as a mechanism to describe the sub-tests carried out for a TestCase. Basically it is an RDF list with all sub-tests executed. It is also imaginable that this list is directly incorporated into the TestCase construct. There may also be other solutions which we need to develop in the new EARL version.

- Confidence
The usage of "Confidence" is quite unclear and needs to be defined in the processing model. For example, it could be tied to the TestCase/Evidence structures, and how these tests were carried out (e.g. automatic / manual / heuristic).

- Message
This is purely for human consumption and should not include any information that may need to be processed by machines. In fact, sometimes it make sense to just point a URI to the error message within a published test description. Also, messages need to support any natural language.


* EARL Processing Model
Very closely related, we need to define a processing model for how to use the structure. This would help developers and considerably reduce fragmentation of the specification by incompatible interpretations. To describe the "location" of an error, there are probably two key components to consider, and tools will need to go into different "modes" accordingly:

- Nature of the Subject
For example: if the Subject is an XHTML document that makes extensive use of IDs, XPath maybe an optimal approach to localize the specific subject we are talking about (e.g. "this table header"). Conversely, if the Subject is a black-box (e.g. application etc), tools may only be able to use a URL to point to it (e.g. "the error is somewhere here").

- Nature of the TestCase
For example: if the TestCase is context-sensitive or context-free, tools may generate different "pointers" from a pre-existing selection of patterns. An attempt at this can be found here:
 <http://lists.w3.org/Archives/Public/public-wai-ert/2005Mar/att-0062/errors.html>


* Conclusion
It seems that we need to do considerable work on the "Processing Model" level which will throw down requirements onto the underlying "Structure". For example, for "locating" an error we need to list the different "situations", and what to do in such cases. This will focus the scope of the Subject/Location structures, and how they should look like in detail. Similar approach should be applicable to TestCase/Evidence as well as Confidence discussions.



Regards,
  Shadi


---                                                    --- 
Shadi Abou-Zahra,  Web Accessibility Specialist for Europe 
World Wide Web Consortium (W3C),        http://www.w3.org/ 
Web Accessibility Initiative (WAI), http://www.w3.org/WAI/ 
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 Friday, 1 April 2005 12:38:27 UTC