Re: [Fwd: Re: Location Property]

[forwarding to list]


-------- Original Message --------
Subject: Re: [Fwd: Re: Location Property]
Date: Fri, 12 Aug 2005 19:54:23 +0000
From: Al Gilman <Alfred.S.Gilman@IEEE.org>
To: public-wai-ert@w3.org
CC: Chris Ridpath <chris.ridpath@utoronto.ca>
References: <42DD8701.4020703@w3.org> <42FB6B5A.80308@w3.org>


At 5:14 PM +0200 8/11/05, Shadi Abou-Zahra wrote:
>Hi Chris,
>
>Great summary of the situation and thanks for the proposal, it's 
>something to start working with. I'll put it on the agenda for this 
>Tuesday's call. Please find a couple of comments below:
>
>
>Al Gilman wrote:
>>In any case, what we need here is an association between formal
>>(generic to the rule-pattern) items in the testable assertion and
>>actual, specifically identified instances of the relevant roles in the
>>generic rule.
>
>Agreed. Here is a previous attempt to list generic patterns for 
>locating errors according to the type of test/error (i'd be happy to 
>help work more on that if you think it is usefull):
>  <http://lists.w3.org/Archives/Public/public-wai-ert/2005Mar/att-0062/errors>


[FWIW $.02]


I think that we should look at XPath and CSS selector expressions
that match our cases. As you suggested elsewhere, here.

Terminology: I think that you use 'validity' too broadly in that
draft. I am afraid that conformance to WCAG takes too much human
judgement to be in the same class of qualities as validity to some
formal statement of a format. [Mimasa's remarks about the
HTML/Math/SVG DTD work pertains. He could validate to a DTD, to a XSD
schema, or to a RNG schema; but no two of these enforced exactly the
same set of constraints.] I suggest we use some terminology more like
"conformance accounting" for recording articulable discrepancies
between a requirement-pattern and an in-scope pattern-instance.

It's like rules take the form

IF <situation-constraint-pattern>
 THEN <injunction-constraint-pattern>

A discrepancy or violation instance is a structure where
the IF pattern succeeds (evaluates to True) and the THEN pattern 
fails (evaluates to False).

The 'problem location' information we need is the mapping between 
situation-contraint-pattern
points and instance-data-points under which this {True, False} valuation holds.

See also
http://lists.w3.org/Archives/Member/w3c-wai-cg/2005JulSep/0012.html

>>>2) The location properties that we use to describe the error is 
>>>dependant on the accessibility test that is performed. For 
>>>example, the properties used to describe HTML errors will be 
>>>different from the properties used to describe errors in Flash or 
>>>PDF.
>>
>>I don't see how we can do diagnostic assist without cacheing an image
>>of the exact message that came over the wire.
>
>There are several issues here: 1. different document types, and 2. 
>content changing over time. I think we agreed not to make issue 2 a 
>top priority right now because it makes the whole idea way too 
>complex. We *are* addressing the content in a more robust way in 
>EARL right now (storing HTTP request/response pairs). We can also 
>built in caching specific content types (such as images) or using 
>signatures later on.
>
>>>3) The location properties should be precise and interoperable. We 
>>>need to describe as clearly as possible where the error occurred 
>>>and this should be done in a standard manner so the results may be 
>>>exchanged with other programs. I suggest that for HTML errors we 
>>>require that at least one xpath expression be used to describe the 
>>>accessibility error.
>>
>>
>>Interoperable, yes.  Standard, no.
>
>Maybe not a required standard but why not propose a method to 
>approach basic Web pages? We will not be able to address all content 
>types but I think we can make a pretty good attempt at some of the 
>basic (and common) ones like HTML, XHTML, CSS, etc. As EARL is then 
>taken up by developers and technologies evolve (eg. PDF does use 
>more XForms etc), we may be able to narrow down the constraints.

My point is that the second party receiving your abbreviated report
should be able to deterministically and repeatably find what you are
talking about in the verbatim copy you cached from the wire
transmission.

I don't think it is necessary that we require ourselves to define a
canonical path particularly in the presence of broken markup.

But I have no problem with offering example service libraries that
extract paths that work.

>>>4) More than one location property may be required. For example, 
>>>to describe a series of links that should be grouped with a list 
>>>element, properties to identify all the links in the group would 
>>>be required. The number of location properties is dependant on the 
>>>accessibility test. If more than one location property is used 
>>>then each property must have a title to describe itself.
>>
>>
>>ID, not title.
>
>Both? ID for machines, title & description (of the location, not of 
>the actual result/error) for humans. This is especially useful for 
>tests or content that is difficult to address programatically and 
>needs to be described.

The human-needed labels are part of the generic description of the
test pattern, I think.

In booking individual discrepancies, we just us something that is a
sufficient key to align the criterion-pattern with the matching
instance data. We don't carry along all the generic stuff with each
discrepancy record.

Human review of the problem will indeed present the labels as part of
the problem analysis. But that is because the human-interfaced tool
follows the path from the discrepancy record to the criterion pattern
to the heuristic explanation.

>
>
>>>5) Other optional location properties may be included. For example 
>>>line and column numbers could be included as well as xpath 
>>>expressions.
>
>Yes. Though we should heavily promote XPath and provide guidance on 
>how to do expressions. How about earl:offset for byte values as well?

Row/column presumes HTTP transmittal so there are frequent EOL breaks.
Or else a standard pretty-print.  I would shy away from row/column use.

There is no assurance that there are row and column coordinates for
objects retrieved by file: URIs, for example.

There are i18n issues with indexing characters.  Doesn't XPath now have
enough plain-text matching capability to do pointers that are as fine as we
could need?

>>>6) The location properties apply to the content evaluated and do 
>>>not necessarily locate the error when the document has been 
>>>modified.
>
>Agreed, this is another beast. I think with the current catching of 
>the HTTP request/response we can at least nail down that the content 
>is different. How it changed may be something for later (even though 
>it is good to always keep it in the back of our heads).
>
>>>7) Other location 'hint' properties may be included for finding 
>>>the error if the document is modified.
>
>Do you mean something like earl:checksum or similar?

I don't think so.  That [I presume] only warns you that the document 
_has_ been modified.

Again, I would do this with XPath by including facts in the path 
expression that are above and
beyond what it takes to make the destination unique.  Things like 
"any ancestor element that
has a navigation-related 'role' value identified shall have that 
'role' value captured into the
path expression."

But that's a good practice that aids in matching an old discrepancy 
against a new page.  Not
something essential to be able to interpret a reported discrepancy in 
a way that's portable
across tools.

Thanks for letting me blather on this.

Al

>>><earl:Location>
>>><rdf:Bag>
>>><rdf:li rdf:parseType="Resource">
>>><dc:title>key-element</dc:title>
>>><earl:xpath>/html/body/p/img[@src="rex.jpg"]</earl:xpath>
>>><earl:column>24</earl:column>
>>><earl:line>9</earl:line>
>>></rdf:li>
>>></rdf:Bag>
>>></earl:Location>
>
>I suggest something like this (not tested):
>
><earl:Locations rdf:parseType="Container">
>  <earl:Location rdf:id="...">
>    <rdf:Bag>
>    ...
>    </rdf:Bag>
>  </earl:Location>
>  <earl:Location rdf:id="...">
>    <rdf:Bag>
>    ...
>    </rdf:Bag>
>  </earl:Location>
>  ...
></earl:Locations>
>
>This would allow multiple occurences of a result within a single 
>resource (i think something like this had been posted to the list 
>earlier already).
>
>
>Regards,
>  Shadi
>
>
>--
>Shadi Abou-Zahra,     Web Accessibility Specialist for Europe Chair 
>and Team Contact for the Evaluation and Repair Tools WG World Wide 
>Web Consortium (W3C),           http://www.w3.org/ Web Accessibility 
>Initiative (WAI),    http://www.w3.org/WAI/ WAI-TIES Project, 
>http://www.w3.org/WAI/TIES/ Evaluation and Repair Tools WG, 
>http://www.w3.org/WAI/ER/ 2004, Route des Lucioles -- 06560, 
>Sophia-Antipolis -- France Voice: +33(0)4 92 38 50 64           Fax: 
>+33(0)4 92 38 78 22

Received on Monday, 15 August 2005 14:57:22 UTC