RE: on EARL

comments below


> -----Original Message-----
> From: w3c-wai-er-ig-request@w3.org 
> [mailto:w3c-wai-er-ig-request@w3.org] On Behalf Of Charles 
> McCathieNevile
> Sent: Montag, 07. April 2003 14:10
> To: Shadi Abou-zahra
> Cc: w3c-wai-er-ig@w3.org; 'Wendy A Chisholm'
> Subject: 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.

i still disagree on this. why not have an assertion conducted by an
assertor that speaks 0.95 and a second assertion by an assertor that
speaks 1.0 within the same EARL file?


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

agreed. having 'temporal stability' is also useful to compare different
test runs conducted on the same subject that might have changed over
time...


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

will dig more around here. only i want to try to get away from analyzing
the "who is making the claim" part and concentrate on the "based on
what" part. does this make any sense at all?


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

hmmm. ok, maybe "priority" is a bad concept but leaving the message
definitions totally in the hand of the assertors requires you to know
who the assertor is in order to interpret these messages.

what about defining a minimal message scheme for subclasses such as
'webcontent' for example? this way all assertors that conduct tests on
webcontent provide a common set of messages about the results. was this
the intention of the earl:message element at all?

regards,
  shadi

Received on Monday, 7 April 2003 18:41:39 UTC