- From: Shadi Abou-Zahra <shadi@w3.org>
- Date: Fri, 10 Feb 2006 18:51:36 +0100
- To: Carlos Iglesias <carlos.iglesias@fundacionctic.org>
- Cc: public-wai-ert@w3.org
Hi Carlos, I think many of the customized reports can (and should) be generated through by queries. Ideally, the full data should be available somewhere in a repository. Depending on the role of the developer, and what information they want from the system, queries are run over the data and customized reports are returned. There are already enterprise evaluation tools that provide this functionality (but with proprietary formats). Of course, now people want to jump on me and tell me that I am insane because it is too much verbose RDF/XML text. I think there are ways of reducing this, for example by storing the data in relational databases that have a RDF interfaces (look at some of the Jena implementations for example). This way, the data can be accessed using RDF and RDF-based query languages, yet benefit from the database features in reducing the storage size and processing time. However, this does not mean that your proposal is not useful. I think it is a good approach to provide different means of describing the scope. For example, by regular expressions as you suggest. One challenge will be sites that use sessions or that use some sort of content negotiation (such as language negotiation). This was the reason why we are developing the HTTP-in-RDF stuff, to really pin down the exact delivery units that have been tested as opposed to the mere URI of the resource. Regards, Shadi Carlos Iglesias wrote: > > 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 > > > -- Shadi Abou-Zahra Web Accessibility Specialist for Europe | Chair & Staff Contact for the Evaluation and Repair Tools WG | World Wide Web Consortium (W3C) http://www.w3.org/ | Web Accessibility Initiative (WAI), http://www.w3.org/WAI/ | WAI-TIES Project, http://www.w3.org/WAI/TIES/ | Evaluation and Repair Tools WG, http://www.w3.org/WAI/ER/ | 2004, Route des Lucioles - 06560, Sophia-Antipolis - France | Voice: +33(0)4 92 38 50 64 Fax: +33(0)4 92 38 78 22 |
Received on Friday, 10 February 2006 17:51:43 UTC