EARL project review notes

The IRC log for the technical review was not very good.  However, here are the basic bits that I was able to collect or recollect.  We spent most of our time discussing the first 3 issues that I raised.  I quickly summarized the other issues, with minor discussion about issues with XPointer.  

1. Identifying Resource State Changes
http://www.w3.org/2001/Talks/12/13-EARL-techreview/slide16-0.html

it was suggested that we check out how XML Signatures deals with the issue. i.e. fingerprints
http://www.w3.org/Signature/

Another option (instead of hash) was "shingles" (suggested by Eric Miller). Shingles give different weights to different structural parts of a document. e.g., you might want to pay more attention to images than to other parts of content (w.r.t. accessibility).  If you want to know HOW content changes, this is more an area of research. Shingles are just one mechanism. 
http://www8.org/w8-papers/4c-server/mirror/mirror.html
http://www.research.compaq.com/SRC/articles/199707/cluster.html

However, when we discussed Nick's hash hack in more detail, they seemed to agree this was the easiest and best method to use. It is more similar to what dsig does.  If we have further questions, Joseph Reagle is willing to discuss this with us in more detail.

Another idea (from danbri) "to define XSLTs that strip textual content from XHTML docs, then run hash over the result. This would let us check for structural changes in a doc, ignoring edits to prose" 

2. Combining and Querying Results 
http://www.w3.org/2001/Talks/12/13-EARL-techreview/slide17-0.html 
The overall feeling was that it is up to the implementation.  Issues raised were those of trust and conflicts.   
- Does the user using the tool decide the level of trust? 
- How do you merge conflicting assertions?

3. Identifying Evaluation State Changes
http://www.w3.org/2001/Talks/12/13-EARL-techreview/slide18-0.html 
We discussed how it is up to the implementation to do a few things based on convenience for the user.  For example, if someone wants to see the history, they should be able to.  However, they might not always want to see the history so sometimes it ought to be hidden.

Marja, Ralph, and Eric were on the phone, so we had a brief discussion about annotations.
Marja said, that there could be different types of replies, such as 'I disagree', 'I make this obsolete'  Some types of replies are pre-defined, but obsolete is not one of them.   

We agreed to have more discussions with the annotea folks.

When I asked if we should add "supersedes" or "replaces" or other values to handle relationships, 
there was a strong reaction against adding anything "just in case."
http://c2.com/cgi/wiki?YouArentGonnaNeedIt
http://www.extremeprogramming.org/rules/early.html


Questions for consideration:
1. A few complicating issues: content and language negotiation; they may or may not affect accessibility evaluations. 
2. CC/PP provides small schema of info on resources. If people buy into RDF, then should buy into re-use, and should check out CC/PP predicates.  Is CC/PP dependency with EARL accepted? The big win from CC/PP is that you can define a variation on a document -if you get back a document and not a location header. EARL can use CC/PP info to evaluate the content in the context of the device on which it will be used 

Danbri published some rough notes on EARL
http://lists.w3.org/Archives/Public/www-archive/2001Dec/0099.html
and sbp's response:
http://lists.w3.org/Archives/Public/www-archive/2001Dec/0111.html

-- 
wendy a chisholm
world wide web consortium 
web accessibility initiative
seattle, wa usa
/--

Received on Monday, 21 January 2002 10:41:21 UTC