W3C home > Mailing lists > Public > public-wai-ert@w3.org > April 2005

Re: EARL structure and processing model

From: Carlos A Velasco <Carlos.Velasco@fit.fraunhofer.de>
Date: Thu, 07 Apr 2005 17:48:48 +0200
Message-ID: <42555660.3030406@fit.fraunhofer.de>
To: shadi@w3.org
Cc: public-wai-ert@w3.org

Hi Shadi, all,

Jumping a little bit on the wagon, and trying to catch up a little bit 
with the frenetic email activity of the WG. Just a short reflexion on 
some of the threads that we consider important (some of this I discussed 
internally with Johannes).

Shadi Abou-Zahra wrote:
> ...
> - 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.

I see we are constantly refering to a "page" (probably is not 
intentional), but maybe we shall refer to a "resource" (which might not 
even contain markup and might not even be on the Web). The most 
reasonable way to refer to it via an URL (+headers, if applicable), and 
I think there is consensus on this from what I see in the exchanges. In 
this case, the MIME-type of the resource will be a useful information as 

> - 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.

Here our bias is more evident, in these threads:

have appeared interesting discussions, like the use of XPath, line and 
column numbers, etc. with their pros and cons. But what if the resource 
is a non-SGML or non-XML, e.g., plain text, or it dares to be a binary 
resource (e.g., PDF, or an image)?

I believe that EARL shall be flexible enough to allow different Location 
approaches depending on the resource's type. I don't have any brilliant 
solution at the moment, but it is something we must include in the 
requirements. We shall not simply disregard these resources, and then 
say "for that resource, we give only its URL as location of a problem."

Dr Carlos A Velasco - http://access.fit.fraunhofer.de/
Fraunhofer-Institut für Angewandte Informationstechnik FIT
   [Fraunhofer Institute for Applied Information Technology (FIT)]
   Barrierefreie Informations- und Kommunikationstechnologie für Alle
   Schloss Birlinghoven, D53757 Sankt Augustin (Germany)
   Tel: +49-2241-142609 Fax: +49-2241-1442609
Received on Thursday, 7 April 2005 15:50:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:52:49 UTC