W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > October 2001

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

From: Jim Ley <jim@jibbering.com>
Date: Sun, 21 Oct 2001 17:26:29 +0100
Message-ID: <013301c15a53$eb50a1c0$763c70c2@7020CT>
To: <w3c-wai-er-ig@w3.org>

> My 2c worth on the answers to the questions...
> On Sat, 20 Oct 2001, Jim Ley wrote:
>   I'm going to ask some questions about how EARL is to be used, which
>   hopefully allow me to be more focused on what my concerns are and
>   therefore be more constructive:
>   Who/what is the audience for reports?
>   What does this audience do with these reports?
> The immediate audience is primarily tools which interpret the EARL.

So where's the user?

This identifies one of the problems, we have different perceptions of how
it is to be used, in Repair terms, it's not important how you get from the
url to its report, that's up to the authoring/repair tool.  So the
"linking" issue isn't a problem.

In the use to aid accessibility directly for users (as opposed to repair)
then you see search engines doing it, I see users doing it, I am big
believer in the user being the best placed to utilise such information.
This means I see an audience much bigger than yours appears to be - you
have <100 search engines, I have >millions of users - and therefore I
expect much more development, more choice and more users wanting to create
something themselves.

>   Does a query language need to be developed?
> Because this is RDF, we can rely on the existing and developing
> for querying RDF rather than inventing a specialised interface. (For
> optimisation, simple tools may only implement "enough for EARL")

Good, this I agree with absolutely.

>   What happens if there's an alternative to EARL, also in RDF how do the
>   users tools distinguish between the 2?
> If there are alternatives then there are going to be two processes for
> interpretation. If it is in RDF then the namespace declarations are the
> (there is an issue on this at the moment based on whether tools are more
> less likely to understand Dublin Core RDF elements already).

This is what I find unacceptable as it drastically increases the
complexity of the tools, as you say you only need implement RDF "enough
for EARL".  If that requires tools to cope with RDF.  If it was uniquely
identifiable outside of the RDF then it would be much simpler, we can just
pass it to the most appropriate processor, if we can't do this we have to
pass it first to some general purpose RDF processor to know how to process
it, and then it's either got to pass it on again to the various tools I
want to use to process the actual reports.

Do you see some single RDF processor existing on peoples computers?

There are currently no mechanisms in the current User Agents that are
similar, we either have the content coped with internally, or we have
choice as to which other program to use, either through MIME-TYPE or

I think it would be silly to require new user agent capabilities, when if
we just stuck with what's possible now, we wouldn't need to get UA
developers on board, or expect users to change their UA, they can just add
in the tool.  This will make it easier to get a user base, and therefore
encourage people to actually create these reports.

Received on Sunday, 21 October 2001 13:14:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:33 UTC