W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > September 2002

Re: Questions and proposals related to strawman schema from F2F

From: Nick Gibbins <nmg@ecs.soton.ac.uk>
Date: Thu, 26 Sep 2002 15:59:13 +0100
Message-ID: <15763.8385.59644.953722@localhost.localdomain>
To: Wendy A Chisholm <wendy@w3.org>

[ bounced to the list because I am a twit and didn't check the To:
  field - nmg ]

Wendy A Chisholm <wendy@w3.org> writes:

> My response is delayed from taking a holiday then catching up from
> being on holiday.

Same here - apologies for the delay.

>>> 4.  testMode (from 1.0 test)

>> I suspect that EARL needs only one of the two ways of indicating
>> how a test was performed; subclassing Assertor seems intuitively
>> simpler, but explicitly indicating the mode would also work
>> adequately.

> It seems to me that it would make more sense to have a property of
> the assertion rather than subclass the assertor.

This seems reasonable. As I said in my previous mail, either solution
should work adequately, and I'm now tending to agree with your
rationale for making the test mode a property of the assertion.

>>> 5. TestCriteria,  suite, level, excludes (from 1.0 test)

>> The line between a testcase and a criterion is also a bit blurry -
>> are WCAG checkpoints considered to be testcases or criteria?

> In WCAG 2.0 we have 3 levels:
> 1. Guidelines
> 2. Checkpoints
> 3. Success criteria

> a success criterion is the child of one checkpoint and the
> great-grandchild of one guideline.  a checkpoint is the child of one
> guideline and at least one child (success criterion).  a guideline
> has siblings (other guidelines) and more than one child
> (checkpoint).  the root is the document "WCAG 2.0"

> Although, people won't be claiming conformance to Guidelines, they
> will only be testing against checkpoints and success criteria.
> Thus, I think your proposed schema would work for WCAG 2.0
> conformance testing. (I tried it out below...really quick first
> pass...)

> [...] I didn't need to use Criterion, CriterionGroup,
> containsCriterion, or tests.  I really like the idea of tests,
> tho...

Yes, I think that I misunderstood the requirements here and
overgenerated a bit. I was trying to draw a distinction between the
actual testcases (eg. the CSS file that shows whether or a user agent
renders a certain feature correctly) and the things that the testcases
test (eg. the requirement that a certain CSS feature be correctly
rendered for a user agent to be described as compliant). This would
allow there to be more than one testcase which tested for compliance
to a particular requirement (criterion).

Having said that, while it is fairly easy to draw the distinction
between testcases and criteria for user agent tests (such as Ian's CSS
test suite), I can't think of a WCAG-like usecase that needs the
distinction, or indeed in which it is possible to make the

In summary, I agree that we don't need to represent the criteria which
testcases test - as Nick put it, this is too close to a test
definition language.

>>> 6. os, version (from 1.0 test)

>> In the strawman, user agent test subjects are identified by a URI,
>> with a human-readable label being provided using rdfs:label. If it
>> is necessary to explicitly state the OS and version of the UA
>> (rather than implicitly coding this in the URI used to identify the
>> UA), the schema can easily be modified to include os and version
>> properties.

> If each version and os release of a UA is identifiable by a unique
> URI then that should use a URI.  What is the URI for Opera v5 for
> Mac OS X? [...]

Ay, and there's the rub. Expecting any agreement on the URIs used to
identify user agents is probably too much to ask.

> This is similar to identifying the reprof of web content with the
> normalization algorithm used and result.

> Should we include earl properties to uniquely identify test subjects
> (i.e.  normalization algorithm, hash algorithm, hash values for web
> content and os, version for tools)?

How about a slightly different approach - we could add a property to
UserAgent whose value is a literal string which is the HTTP User-Agent
string. If we then adopt DAML+OIL/OWL terminology in a future version
of EARL, this property would be an UnambiguousProperty; two UserAgents
with the same value for this property would be considered to be the
same user agent.

Nick Gibbins                                            nmg@ecs.soton.ac.uk
IAM (Intelligence, Agents, Multimedia)             tel: +44 (0) 23 80592831
Electronics and Computer Science                   fax: +44 (0) 23 80592865
University of Southampton
Received on Thursday, 26 September 2002 11:44:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:34 UTC