Re: EARL and locating a problem...

Well, I agree that EARL could liv without a pointer, but in practice any
repair tool using EARL is going to require this information. UsableNet and
Hisoftware both include it in their reports - Hisoft had to extend the
version of EARL they were using to get anything useful from using the
language for more than report writing, which is really I think a trivial
application of EARL.

Something like a property of the result:

<earl:occuringAt>
  < [some pointer or collection  of pointers] />
</earl:occurringAt>

or we could reuse the approach of Annotea, although I am not sure if they
have somehow restricted themselves to a single point that is being annotated.

The scenario goes as follows:

Tool A has a very good test for problem X, but no real repair functionality.
Tool B has a very good repair interface for problem X, but no good test for
it.

The user runs tool A and discovers that some part of the document needs to be
repaired. They fire up tool B, but unless it knows where the problem is it
cannot invoke the repair function for the right part of the document.

If tool A is required to identify the location as the testObject, rather than
the testObject being a page, then it needs to construct potentially an
Xpointer for that location, and then the information that the rest of the
page plus that location makes up a thing being tested. Given the complexity
of Xpointers, this seems like a very complex general problem - there may very
quickly be dozens of different collections (along different axes) making up
the same page.

If on the other hand we have a property on the result property, then toolB
can look for that relatively easily, declare that problem X has been
repaired, and the merged results

(page Y failed test X at time 1 in locations P,Q,R) and (page Y passed test X
at time 2 in locations P,Q)

give us a new result for page Y at much lower cost than merging a large
collection of partial objects and how they combine to form page Y.

cheers

Chaals

On Fri, 28 Jun 2002, Jim Ley wrote:


  "Charles McCathieNevile" <charles@w3.org>
  > during the meeting we discussed the question of whether earl should
  provide a
  > pointer to where it finds a specific problem within a page, or whether
  it is
  > better to write earl statements about objects within a page, and then
  > describe the page as a collection of objects that do or don't meet a
  given
  > set of requirements.

  My own view is not against the idea of providing a failurePoint or
  whatever, but that the scope of "where it has failed" is too general to
  be in EARL, I think it needs to be an extension, we can hang anything off
  of the resultProperty, but information that locates where in a xml
  document it fails or elsewhere is too specific to be in core EARL.

  So I guess my problem can be solved if you can tell me what would it look
  like in a few of our use cases?

  Jim.


-- 
Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
W3C Web Accessibility Initiative     http://www.w3.org/WAI  fax: +33 4 92 38 78 22
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)

Received on Saturday, 29 June 2002 23:49:27 UTC