Summarizing earl reports

Hi everybody,

In every project we can find different roles, e. g. if we focus on Web projects:

- Project managers
- Content authors
- Programmers
- Web designers
- Graphic designers
- Accessibility specialists
- Usability specialists
- etc.

Each of these roles has different reporting requirements. Quoting [www.w3.org/WAI/eval/selectingtools]:

"Evaluation tools that generate reports sometimes provide capabilities to customize the format of these reports to different degrees. Customizing reports according to the roles of the developers (for example content author, programmer, project manager...) is especially useful for larger development teams"

So, as the group pointed several times in the past, there is a real necessity to provide different levels of detail to better fit different user requirements and, at the same time, allow the production of more compact reports.

The following is a rough proposal for the aggregation or summarization of different parts of EARL reports. From now on, let's work on the basis of the following typical use case:

A development group (with project managers, web designers, accessibility specialist, etc.) is working on a Web site redesign (e.g. about 2000 web pages) for a client, and one of the new requirements of the project is Web Accessibility (it wasn't in the previous design).

They will have several accessibility reports needs along the project life, and this reports will have different verbosity requirements:

- A project manager doesn't need so many details as a web designer or an accessibility specialist.

- At the beginning they will probably found lots of accessibility problems in the original design and detailed reports will be necessary (they need detailed assertions about each of the problems), but as the project matures the accessibility problems decrease, so low level of details may be necessary (they don't need 2000 assertions claiming that everything is OK, they just want an assertion claiming the same).

- Once the redesign will be finished (and the accessibility is OK) the maintenance work will start. They will do frequent reviews (and reports), and probably new problems will appear from time to time (due to the natural evolution of the site and its contents). This new problems need to be reported but, again, low details level may be necessary (They don't want 1995 assertions claiming that everything is Ok and 5 claiming that something is wrong, they just want an assertion claiming that everything is OK with 5 exceptions or exclusions in detail).

There are several ways to provide the information they need with EARL:


FIRST APPROACH
---------------

The more verbose approach could be one Assertion for each piece of WebContent and one WebContent for each resource we need, as in the following example:


<earl:Assertion rdf:ID="assertion1">
  <earl:assertedBy rdf:resource="#assertor"/>
  <earl:subject rdf:resource="#webPage1"/>
  <earl:requirement rdf:resource="#requirement"/>   
  <earl:testcase rdf:resource="#testcase"/>
  <earl:result rdf:resource="#result"/>
  <earl:mode rdf:resource="http://www.w3.org/WAI/ER/EARL/nmg-strawman#automatic"/> 
</earl:Assertion>

... a bulk of hundreds of Assertions more

<earl:WebContent rdf:ID="webPage1">
  <dc:title xml:lang="en">Some Web page</dc:title> 
  <dc:description xml:lang="en">The first page of the Web Site</dc:description> 
  <earl:uri rdf:resource="http://example.org/1.html"/>
  <dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#gDate">2006-01-01</dc:date> 
</earl:WebContent>

... a bulk of hundreds of WebContents more

With this approach applied over our use case web site we will get 2000 Assertions and WebContents pairs. This is also the more detailed approach but, as commented before, this could be not always necessary.


SECOND APPROACH
----------------

This approach show how to provide a basic level of aggregation allowing several earl:subject per assertion (as proposed in [http://lists.w3.org/Archives/Public/public-wai-ert/2005Oct/0019]). For example:


<earl:Assertion rdf:ID="bulk-Assertion">
  <earl:assertedBy rdf:resource="#group_of_people"/>
  <earl:subject rdf:resource="#webPage1"/>
  <earl:subject rdf:resource="#webPage2"/>
  <earl:subject rdf:resource="#webPage3"/>
  <earl:subject rdf:resource="#webPage4"/>
  <earl:subject rdf:resource="#webPage5"/>
  <earl:subject rdf:resource="#webPage6"/>
  <earl:subject rdf:resource="#webPage7"/>
  <earl:subject rdf:resource="#webPage8"/>
  ... a bulk of hundreds of subjects more

  <earl:requirement rdf:resource="#requirement"/>
  <earl:testcase rdf:resource="#testcase"/>
  <earl:result rdf:resource="#result"/>
</earl:Assertion>

<earl:WebContent rdf:ID="#webPage1">
  <dc:title xml:lang="en">Some Web page</dc:title> 
  <dc:description xml:lang="en">The first page of the Web Site</dc:description> 
  <earl:uri rdf:resource="http://example.org/1.html"/>
  <dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#gDate">2006-01-01</dc:date> 
</earl:WebContent>

... a bulk of hundreds of WebContents more


With this approach we will get a unique Assertion, but we still have 2000 WebContents that could be not always necessary.


THIRD APPROACH
----------------

A third approach could allow us a powerful way of aggregation including some additional classes and attributes to earl. We can identify several levels of web content aggregation that could be easily found in evaluation tools. As an example:

- Domain
- Subdomain
- Directory
- Web page (including all related resources: images, objets, css, etc.)
- etc.

So, it seems sensible to provide this level of aggregation on earl reports. 


<earl:Assertion rdf:ID="aggregated-Assertion">
  <earl:assertedBy rdf:resource="#group_of_people"/>
  <earl:subject rdf:resource="#web-site"/>
  <earl:requirement rdf:resource="#requirement"/>
  <earl:testcase rdf:resource="#testcase"/>
  <earl:result rdf:resource="#result"/>
</earl:Assertion>

<earl:WebContent rdf:ID="web-site">
  <dc:title xml:lang="en">Some Web Site</dc:title> 
  <dc:description xml:lang="en">The best Web site of the world</dc:description> 
  <earl:uri rdf:resource="http://example.org/"/>
  <earl:scope rdf:nodeID="Domain"/>
  <dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#gDate">2006-01-01</dc:date> 
</earl:WebContent>

<earl:Scope rdf:nodeID="Domain">
  <dc:title xml:lang="en">Domain Scope</dc:title>
  <dc:description xml:lang="en">All the resources within the specified domain</dc:description>    
  <earl:range rdf:resource="http://www.w3.org/WAI/ER/EARL/nmg-strawman#domain"/>    
</earl:Scope>


With this approach we will get a unique (and much more compact) Assertion and a unique WebContent with an associated scope. Other kinds of scope we could add are:


<earl:Scope rdf:nodeID="Subdomain">
  <dc:title xml:lang="en">Subdomain Scope</dc:title>
  <dc:description xml:lang="en">All the resources within the specified domain and all related subdomains</dc:description>    
  <earl:range rdf:resource="http://www.w3.org/WAI/ER/EARL/nmg-strawman#subdomain"/>
</earl:Scope>
 
<earl:Scope rdf:nodeID="Directory">
  <dc:title xml:lang="en">Directory Scope</dc:title>
  <dc:description xml:lang="en">All the resources within the specified directory</dc:description>    
  <earl:range rdf:resource="http://www.w3.org/WAI/ER/EARL/nmg-strawman#directory"/>
</earl:Scope>
  
<earl:Scope rdf:nodeID="WebPage">
  <dc:title xml:lang="en">WebPage Scope</dc:title>
  <dc:description xml:lang="en">All the resources within the specified Web Page (including the current (x)html, images, objects, etc.)</dc:description>    
  <earl:range rdf:resource="http://www.w3.org/WAI/ER/EARL/nmg-strawman#webpage"/>
</earl:Scope>
  
<earl:Scope rdf:nodeID="Document">
  <dc:title xml:lang="en">Default document Scope</dc:title>
  <dc:description xml:lang="en">Just the (x)html document (excluding images, objects, etc.)</dc:description>    
  <earl:range rdf:resource="http://www.w3.org/WAI/ER/EARL/nmg-strawman#document"/>
</earl:Scope>


Even a "self-defined" scope:


<earl:Scope rdf:nodeID="Pattern">
  <dc:title xml:lang="en">Pattern Scope</dc:title>
  <dc:description xml:lang="en">All the resources that match with the indicated pattern</dc:description>
  <earl:range rdf:resource="http://www.w3.org/WAI/ER/EARL/nmg-strawman#pattern"/>
  <earl:pattern>Some pattern (e.g. a regular expression)</earl:pattern>
</earl:Scope>


And more detailed scopes (to allow fine-grain validations) as:


<earl:Scope rdf:nodeID="Chunck">
  <dc:title xml:lang="en">Chunck</dc:title>
  <dc:description xml:lang="en">A pieze of (html) content</dc:description>
  <earl:range rdf:resource="http://www.w3.org/WAI/ER/EARL/nmg-strawman#chunck"/>
  <earl:begin>Some kind of pointer (related to the location work)</earl:begin>
  <earl:end>Some kind of pointer</earl:end>
  <ear:chunck>The chunck itself or an cheksum...
    <table class="grid">
      <tr>
        <td>Cell 1</td>
        <td>Cell 2</td>
      </tr>
    </table>
    <p>Paragraph with a <a href="http://">link</a> and an <img src="http://"/></p>
   </earl:chunck>
</earl:Scope>


Probably it should be convenient reuse the Range Location idea [http://lists.w3.org/Archives/Public/public-wai-ert/2005Sep/0013.html] instead earl:begin and earl:end, and maybe we could use Evidence instead earl:chunck.


ONE STEP BEYOND
----------------

We could go a (necessary) step beyond adding more expressivity to the language by a new Class which allows to express exclusions or exceptions with the same scopes.

E.g. An assertion about a whole web site with the exception of a directory


<earl:Assertion rdf:ID="aggregated-Assertion">
  <earl:assertedBy rdf:resource="#group_of_people"/>
  <earl:subject rdf:resource="#web-site"/>
  <earl:requirement rdf:resource="#requirement"/>
  <earl:testcase rdf:resource="#testcase"/>
  <earl:result rdf:resource="#result"/>
</earl:Assertion>

<earl:WebContent rdf:ID="web-site">
  <dc:title xml:lang="en">Some Web Site</dc:title> 
  <dc:description xml:lang="en">The best Web site of the world</dc:description> 
  <earl:uri rdf:resource="http://example.org/"/>
  <earl:scope rdf:nodeID="Domain"/>
  <earl:exception rdf:nodeID="private-part"/>
  <dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#gDate">2006-01-01</dc:date> 
</earl:WebContent>

<earl:Exception rdf:nodeID="private-part">
  <earl:uri rdf:resource="http://example.org/private/"/>
  <earl:scope rdf:nodeID="Directory"/>         
</earl:Exception>

<earl:Scope rdf:nodeID="Domain">
  <dc:title xml:lang="en">Domain Scope</dc:title>
  <dc:description xml:lang="en">All the resources within the specified domain</dc:description>    
  <earl:range rdf:resource="http://www.w3.org/WAI/ER/EARL/nmg-strawman#domain"/>    
</earl:Scope>

<earl:Scope rdf:nodeID="Directory">
  <dc:title xml:lang="en">Directory Scope</dc:title>
  <dc:description xml:lang="en">All the resources within the specified directory</dc:description>    
  <earl:range rdf:resource="http://www.w3.org/WAI/ER/EARL/nmg-strawman#directory"/>
</earl:Scope>



FURTHER WORK
-------------

This proposal is just a first step which only takes care about how to express WebContents in a compact way when necessary. The properties and classes names are just a first proposal and could be changed and extended if we find others more accurate.

Obviously, if we decide to follow this path, further similar study should be needed about other EARL components that could be affected and favoured by the aggregation (Requirements, Test Cases, etc.) in search of a complete solution. Other parts of the specification could be also affected (the earl:mode=mixed make sense in an aggregated world)

There are also several issues related to the aggregation that need to be studied (reports comparision, persistence, etc.) and could lead to the discovery of new necessities (e.g. an earl:verbosity attribute)


Waiting for your thoughts...

Regards,

CI.

 
--------------------------------------

Carlos Iglesias

Web Accessibility Unit - CTIC Foundation
Science and Technology Park of Gijón
33203 - Gijón, Asturias, Spain 

phone: +34 984291212
fax: +34 984390612
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org

Received on Thursday, 9 February 2006 17:24:52 UTC