Summary and proposals from 11 December chat

At yesterday's chat [1] we discussed the summary of issues sent last week [2].

>1. severity
>Not incorporated into the schema but used as an example extension.

Agreed this was a good approach.
[http://notabug.com/er/chatlogs/2002-12-11.html#T19-15-13]

>2. repairInfo, expectedResult, suspectAgainst.
>Did not have support. Nothing added to the schema.

All agreed this should be handled by a generic "note" property.
[http://notabug.com/er/chatlogs/2002-12-11.html#T19-14-37]

"message" fulfills the basic purpose, but perhaps a more generic name like 
"note" is more appropriate?
<rdf:Property rdf:about="&earl;message"  rdfs:label="message">
        <rdfs:range rdf:resource="&rdfs;Literal"/>
        <rdfs:domain rdf:resource="&earl;TestResult"/>
</rdf:Property>


>3. operator, operatorInstructions, purpose.
>Did not have support. Nothing added to the schema.

was not discussed yesterday.

>4. testmode
>Had support and was included as a class, a property, and instances of the 
>property.

Discussion about making testmode a property of the Assertor or the Assertion.
[http://notabug.com/er/chatlogs/2002-12-11.html#T18-29-39]

1. If the assertor only has one mode (e.g., a one pass syntax validator may 
only make automatic assertions), modifying each assertion with a mode 
property is redundant.

2. We considered creating a "default mode" that would modify the assertor 
and "mode" on the assertion that would override the default mode.  However, 
there would be issues combining data if one set of assertions assumed a 
default mode and another did not.  i.e., IF (assertor has a mode) THEN 
(assertion inherits it UNLESS assertion overrides it) ELSE (assertion 
SHOULD have its own)

3. assertedBy is already a property of assertion, so if mode modifies 
assertor then mode could be derived from tracing back to the assertor 
(through assertedBy).  However, this is an extra step that we are not sure 
current tools would make.

We had a 2-to-1 split on how to resolve this.  The stronger position is to 
only allow mode as a property of assertion because allowing it on assertor 
requires an extra processing step that might not be handled by current tools.

We did not have a resolution on this.  I propose including this issue in 
the Request for Review that will be sent to the various groups (listed below).

>5. TestCriteria,  suite, level, excludes.  OPEN ISSUE.
>This had some support but some felt it was going too far in the direction 
>of a test point description language.

did not discuss.

>6. os, version. OPEN ISSUE.
>We agreed there is no unique way to identify a UA (i.e., URIs for each UA 
>don't exist).  Thus, I still think these are needed to help uniquely 
>identify UAs.

did not discuss.

>7. snapshot.
>Did not have support. Nothing added to the schema.

would be handled by the reprOf proposal (see issue #9).

>8. date.  TO DO.
>Agreed to use DC:date, but it's not explained in the spec nor is there any 
>representation in the schema.

discussion begins at:
http://notabug.com/er/chatlogs/2002-12-11.html#T19-48-02

I took an action to ask danbri or eric or someone and look at other schemas 
to see how they import terms from other schema.

>9. Uniquely identifying pieces of content. OPEN ISSUE.
>The draft says nothing about how to handle changes to content identified 
>by an xpath that changes and breaks the xpath.  I still think this is 
>something that needs to handled separately (i.e., i don't think we want to 
>propose a solution in the EARL 1.0 spec itself) I do think we need to 
>raise awareness of the problem and pose possible solutions
>(e.g., 1. if a repair tool: add a unique id to each element you annotate,
>OR 2. use hashes to help determine what changed,
>OR 3. if interactive: ask the user to confirm that the element being 
>referred to is correct, etc etc).

discussion begins at: http://notabug.com/er/chatlogs/2002-12-11.html#T19-16-58

We had consensus to propose using reprOf  as a property to TestSubject that 
can be used as a generic hook to  describe processing/derivation - e.g. an 
XPath/XPointer, checksum, snapshot, line/column, set of HTTP headers, a 
description of process and results including a snapshot, a webservice that 
reproduces the processing,  points to the piece of source code that 
provides the functionality in question (if TestSubject is software), 
etc.  Thus, what goes into reprOf will be an extension.

Currently, the schema says:
<rdf:Property rdf:about="&earl;reprOf" rdfs:label="reprOf">
  <rdfs:range rdf:resource="&rdfs;Resource"/>
<rdfs:domain rdf:resource="&earl;WebContent"/>

We propose changing it to:
<rdf:Property rdf:about="&earl;reprOf" rdfs:label="reprOf">
<rdfs:domain rdf:resource="&earl;TestSubject"/>

Leaving the range open so that people can extend as needed.  Also, we would 
include an explanation that describes a variety of possibilities for 
extensions (ala the above examples).

>I would like to send a request for review to the RDFIG, the annotations 
>list (www-annotation), and the QAWG.  Are  there other groups that we 
>ought to send this to?

added to the list: web-ont, validator, and niq may forward on to some 
usenet groups.  I plan to send a request for review by next week. I would 
like to discuss the other open issues first.
[http://notabug.com/er/chatlogs/2002-12-11.html#T19-07-28]

Thanks,
--wendy

[1] http://notabug.com/er/chatlogs/2002-12-11.html
[2] http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2002Dec/0001.html

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--

Received on Thursday, 12 December 2002 12:27:32 UTC