- From: Jim Ley <jim@jibbering.com>
- Date: Wed, 3 Jul 2002 22:30:54 +0100
- To: "WAI ER group" <w3c-wai-er-ig@w3.org>
"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