[w3c-wai-er-ig] <none>

e793c3@y0r1d9>
Subject: Re: Where does the EARL go?
Date: Sat, 20 Oct 2001 10:53:23 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

Sean:
> EARL is an application of RDF.

Hence my problem with the technical solution coming before the human, as
you've described EARL it doesn't fit the job, because there's no way for
me to use an EARL report on a url.

<pretend EARL doesn't exist>
It would be useful to have a machine readable format for reporting on the
accessibility of URI's.

To use a reporting language, I need to be able to identify that it is a
report and hand it off to my processor to provide in human readable, or to
make judgements about links for me.

In HTML the use of the LINK element seems to be appropriate for linking to
the report, there are certainly no others within the current
recommendations.  The LINK though is poorly mentioned in the standard:

"Authors may use the following recognised link types, listed here with
their conventional interpretations. - -"
http://www.w3.org/TR/REC-html40/types.html#type-links

and then proceeds to list them which are in no way conventional, or what
they might actually mean.  However it would seem sensible to add an
"accessibility report" for this to be useful, it could be done in multiple
formats, then you could write (generate from the machine readable) an HTML
version of the report in addition to the machine-readable. e.g.

<LINK rel="accessibility-report" href="/report.html" type="text/html">
<LINK rel="accessibility-report" href="/report.arl"
type="text/x-accessibility-reporting-language">

The strength of the alternative versions being the user doesn't require an
interpreter of our machine readable format, and could still learn about
the report/get contact details.  Or also for allowing future development
where more than one reporting language can be used in the same HTML
document.

This does though require a mime-type - as a generic RDF or text/plain or
text/xml causes future problems, if we use text/plain then I would expect
a user to be able to understand it as is. if we use a generic RDF, what do
we do with future reporting languages, or even evolutions of the current,
there's no way of identifying it, so we'd be limited to evolving the
current language and then with constraints.  Of course you could use an
alternative method in the LINK element to say the type/version of the
reporting language, but that would need an extension to the LINK element,
unlikely and unwarranted.

Then there's resources which aren't HTML (or other resource where linking
is possible.), how do we provide a mechanism whereby the user can get at
these reports.   There are 2 possible solutions I can see, one is an HTTP
request of the same url with an accept header asking for an accessibility
report of that resource.  This would require a mime-type, and can't be a
generic (as then you couldn't create accessibility reports for any of the
generics.)  The other has less support in the existing framework, other
than by general agreement, this is the robots.txt file, which wouldn't
need its own mime-type, but I struggle to see how this could really be
effectively suggested on sites with radically different reports, how would
you do the association within the reporting language, and the report would
quickly get very large.

<EARL exists again>

So how does EARL fit in the above framework?  Well it doesn't if we can't
give it a mime-type, other than the last one, which seems to suffer other
problems with the current EARL framework.

Jim.

Received on Saturday, 20 October 2001 05:53:33 UTC