W3C home > Mailing lists > Public > public-wai-ert@w3.org > September 2006

issues addressed (was Re: Updated EARL 1.0 Schema Editors' Draft)

From: Shadi Abou-Zahra <shadi@w3.org>
Date: Tue, 19 Sep 2006 13:07:19 +0200
Message-ID: <450FCF67.9010104@w3.org>
To: Carlos Iglesias <carlos.iglesias@fundacionctic.org>
Cc: public-wai-ert@w3.org

Hi Carlos, Johannes,

Thanks for your comments and responses. This is to document how the issues you raised (and discussed later in this thread) have been addressed. An updated editors' draft and an issues list will follow later today in a separate thread.


Carlos Iglesias wrote:
> * "This version" and "Previous published version" links are incorrect

Fixed, thanks.


> * 1.1 Structure of EARL Results
> 
> "Test Subject
>   This can include: Web pages, tools..."
> 
> IMO it should be: Web CONTENT, tools...

All three examples in this section have been reworded to provide more clarity. However, note that this whole section will be synchronized with the EARL 1.0 Guide.


> "Test requirement
>   What are we evaluating the subject against?..."
> 
> IMO we should adopt the new wording to avoid confusion (i.e. "Test
> Criteria" instead of "Test requirement"). The same applies to the rest
> of the document (Examples 2 and 3, the introduction at the 2.1 Assertion
> section and the earl:result description at the same section)
> 
> Other times "Test Statement"  is used to refeer "Test Criteria", again I
> suggest use always "Test Criteria" (This happens in the earl:test
> description at the 2.1 Assertion section and in the earl:fail and
> earl:notApplicable descriptions at the 2.6.1 Validity level section)

Fixed (using "Test Criterion" as proposed by Johannes), thanks.


> * 2.2 Assertor
> 
> "foaf:Agent
>   ... An Agent is a super class of foaf:Person, foaf:Organization and
> foaf:Group which can all be used to describe an Assertor..."
> 
> Due to this description I think that the previous foaf:Person section is
> redundant and not necessary (why a section for Person and not for
> Organization or Group?)

This part (and the relevant parts in the "Terms" section) have been reworded to provide more clarity.

However, there are some advantages to describing foaf:Person separately because of its unique stability in relation to the other foaf:Agent sublcasses. There is also a question about making earl:Software a sublcass of foaf:Agent. Both these issues have been listed on a separate issues list for later discussion (not a reason to stop publication I think).


> * 2.5 Test Mode
> 
> "earl:mixed
>   Where there is no detailed information about the test mode
> available..."
> 
> IMO should be something like:
> 
>   Where THE TEST WAS PERFORMED BY AN UNKNOW COMBINATION OF AGENTS AND/OR
> TOOLS...
> 
> To avoid confusion with an "unknow" mode (no information at all)

This definition has been reworded to better clarify the meaning of this value (see a separate thread about the earl:unknown valaue for the test mode).


> * 2.6.2 Confidence Level
> 
> "...This may be used where a tool wants to assert..."
> 
> Is the confidence level supossed to be just for tools?

Fixed (implemented the wording suggestion from Johannes), thanks.


> Additionaly, I think that Example 11 perfectly explains why the
> confidence property makes no sense in EARL as currently developed. It
> says:
> 
> "...the interpretation of this value is application specific..."
> 
> IMO it make no sense to include a propery for application specific
> values in a language to share data between applications. If you need
> something specific to your application you should extend the language
> for your specific use case.

I've added this comment to a separate list of issues for discussion. However, we've had this discussion in the past and we concluded that the benefit of keeping this stub inside the schema is for providing uniform mechanism to add this type of information. It is likely that later versions of EARL may refine this concept depending on the adoption amongst tool developers.


> * 2.7 Software Tool
> 
> I find the Example 13 obscure. It says:
> 
> "The software which was an Assertor in example 5 is now a Test Subject"
> 
> But that's not clear in the example. IMO could be better:
> 
> The software which was an Assertor in example 5 could also be used as a
> Test Subject and make use of the inherited properties

Fixed (wording has been improved and the software class has been enclosed into a subject property as proposed by Johannes), thanks.


> * 4 Conformance
> 
> "An EARL Report is a set of instances of the Assertor class called
> assertions..."
> 
> Sounds weird. Should be?:
> 
> An EARL Report is a set of instances of the ASSERTION class called
> assertions...

Fixed, thanks.


> * Appendix A: EARL 1.0 Schema in RDF/XML
> 
> The xmlns:dct is missing

Fixed, thanks.


> * The Appendix C section (changes) is apparently not up-to-date

Work in progress...


> * Appendix E and F should be renamed to D and E respectively as they are
> in the table of contents

Fixed, thanks.


> * Some typos
> 
> 2.5 Test Mode: "querries" instead of "queries"
> 2.6.3 Instance Location: "re" and "occurence" instead of "occurrence"

Fixed, thanks.


Regards,
  Shadi


-- 
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 Tuesday, 19 September 2006 11:10:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:27 GMT