Re: on EARL

Comments inline - quick summary: version is not necessary, different location
specifiers are required but should be in RDF, not extra properties for
line/column, line/col is the least accurate reference over time, test-case
nesting is critical but maybe doesn't belong in the EARL spec itself, you can
already put complex annotations into an earl:note so priority isn't a
particular need.

On Mon, 7 Apr 2003, Shadi Abou-zahra wrote:

>ref: http://www.abou-zahra.net/shadi/w3c/wrapper/outline.html
>
>here are some comments i have about EARL:
>
>1. EARL versions
>considering the fact that there are already two versions of EARL, a
>dedicated earl:version attribute would be very helpful so that a
>consumer tool can determine if it has the capability to process the
>input. currently the only possibility is to look at the namespace value
>but in my opinion that is a hack.

I don't think this is a hack, because the EARL namespaces identify each
version differently - this is therefore providing some identifier for the
given version, in line with the use of namespaces in XML and RDF. Which is,
IMHO, better than adding a version property to an EARL assertion.

>2. location specification
>even though the earl:subject attribute might describe a tested DOM
>*element* fairly well (eg.
>"http://www.example.org/page.html#html[1]/body[2]/img[1]"), in many
>cases a cursor to the specific location within a *file* (eg.
><earl:cursor row="23" col="15"/>) might be more appropriate, for example
>if the consumer is an authoring tool that needs to point an end user to
>that location.

This was discussed some time ago, and I was under the impression that the
subject would be expected to be RDF - this allows for it to be a single RDF
resource such as an Xpointer, some RDF that refers to a line/character offset
(Hisoft do this in their AccVerify EARL reports), a more complex kind of
pointer such as a fuzzy pointer, or something that says "the tool whose
homepage is http://example.org/authTool".

Providing just a line/character offset is the least stable way to refer to
something, since many authoring tools change these even without changing the
document - just by allowing for a human-readable source view. Conversely they
are the easiest to generate from an Xpointer or similar, which specifies more
than just the starting point. In the authoring tool case being able to track
something over changes in the page is particularly important, so stability is
desirable. There is a discussion that took place some time ago about various
techniques for doing this, but I don't have a pointer handy.

>3. test case nesting
>having child/parent relationships for test cases might be very helpful
>in understanding the assertions and possibly making a judgment on
>severity and importance of a failure or success. for the tool i am
>trying to build such a description would also allow me to align
>assertions conducted by different assertors without getting into any
>tools specifics.

I don't recall if this is in the spec, but we have certainly discussed this
as a requirement - for example at the Bristol face to face meeting. It may be
that these were defined utside the specification - for example I think the
RDF information about WCAG that is used in the MUTAT sample claims that
certain test (e.g. WCAG level A conformance) can be determined heurisitcally
based on other tests (in this case all the priority one WCAG checkpoints)
which may themselves each be determined by several tests (there are several
tests available for WCAG1 checkpoint 1.1 in AERT that all need to be met or
not applicable in order to assert conformance to the checkpoint). This
appraoch is also important for testing WCAG and section 508 - a number of the
same tests are used and some different ones. It would be worthwhile lookin at
commercial tools such as AccessValet, AccVerify, LIFT, etc. to see how they
handle this.

It is also important to have information about who is making the claim, based
on what. I know of at least 3 different analyses of the relationship between
508 and WCAG, which could give different results for overall conformance
based on a seres of atomic test results.

>4. multiple messages
>an assertor might have a lot to say about a conducted test but not
>everything might be equally important to the end user depending on their
>role. being able to tag an earl:massage with a priority or similar might
>be useful for flexibility.

You can put anything you like into the RDF for a message, no? Datatyping, use
of different languages, or referring to an RDF resource which has a schema
describing lots of things about the message, and is provided as one possible
result of a test...

Setting the earl priority scheme is probably a mistake because it seriously
limits the generality of the solution.

cheers

Chaals

-- 
Charles McCathieNevile  http://www.w3.org/People/Charles  tel: +61 409 134 136
SWAD-E http://www.w3.org/2001/sw/Europe         fax(france): +33 4 92 38 78 22
 Post:   21 Mitchell street, FOOTSCRAY Vic 3011, Australia    or
 W3C, 2004 Route des Lucioles, 06902 Sophia Antipolis Cedex, France

Received on Monday, 7 April 2003 08:10:11 UTC