Re: EARL and locating a problem...

"Charles McCathieNevile" <charles@w3.org>
> Well, I agree that EARL could liv without a pointer, but in practice any
> repair tool using EARL is going to require this information.

I think we're in agreement really, We need to define a pointer to parts of
HTML (and other ML) documents, Nick's fuzzy pointers and hashes and other
approaches (real xpointer, and simple line/column) do that, so we need to
describe these.  Once described they can happily hang off both testSubject
and resultProperty without problem as I see it.

Will they be in the EARL namespace?  Or is this another area we also want
to describe, which can be extended seperately to the EARL.

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

I'm not completely sure I agree with this analysis, if you can divide the
page in to atoms, and say an atom has failed and then been repaired it's
pretty much the same cost, we're just describing the atom at different
points.  I think it depends on how much you see PASSED being used - to me
it's a rarity in HTML page repair, where what we really want to know is
has the suite passed (none of the tests failed) and how we can repair each
fail so as I see it you'll only get FAILS being created in which case it
is the same cost if the pointers are in testSubject or resultProperty.

I certainly have no problem with resultProperty having a occurringAt or
similar.

Cheers,

Jim.

Received on Wednesday, 3 July 2002 17:31:11 UTC