SV: 28 May 2001 WAI ER WG Telecon

Thanks for having me on the call, I look forward to continuing the
discussion

/Dimitris

-----Ursprungligt meddelande-----
Från: Wendy A Chisholm [mailto:wendy@w3.org]
Skickat: den 28 maj 2001 17:43
Till: w3c-wai-er-ig@w3.org
Kopia: dimitris.dimitriadis@improve.se
Ämne: 28 May 2001 WAI ER WG Telecon


http://www.w3.org/WAI/ER/2001/05/28-minutes.html

28 May 2001 WAI ER WG Telecon

Summary of action items and resolutions
·       Action SP fix style sheet in EARL doc to work with older versions 
of Netscape
·       Resolved: Will continue to discuss at next week's joint AU/ERT 
meeting: how to sell this to developers. What info can we pass to DiD to 
convince harness developers to make harnesses generate EARL.
·       Action CMN/WC: follow-up on AU/ERT discussion with DiD.

Participants
·       Daniel - DD
·       Sean
·       Chris
·       Wendy
·       Dimitris Dimitriadis (from DOM WG) - DiD
·       Charles

EARL 0.95
Action SP fix style sheet in EARL doc to work with older versions of
Netscape
DD Where are the graphics? Are they linked from anywhere.
SP On my infomesh site.
DD Danny Ayers images were nice, perhaps link to?

Open issues from EARL Issues - Again, 21 May 2001
DD Don't think we can resolve until people use. Should maintain a page that 
lists all of the issues and perhaps users can propose solutions.
WC Open ended questions versus do one way or the other. What about DAML 
questions? Follow up with Dan C?
SP Yes, and several others and all seem ok. There are issues, but those are 
within the RDF world.
SP Primary issue is prose - more prose in schema to identify what each 
property means.
DD Should be self-documenting. Should we do it this way or have separate 
documentation.
SP Dan and Tim maintain N3 and generate RDF and XHTML using XSLT.
DD We should work on XHTMLfile and use that to point at the documentation.
SP How much of definition in schema and how much pointing to the outside?
DD Primer - details, graphics, etc. Keep reference doc in the schema.
SP Refer to the primer as a whole? W/in schema point to primer?
DD We should have feedback from the user.
SP Expect some people prefer in documentation, other prefer to have in
schema.
DD Currently EARL home page is primer, what we call primer is extended doc. 
Instead should call the model something else. Right now, should work on 
primer, documentation, and home page.
/* Dimitris joins - DiD*/
SP Dan suggests putting example on home page. However, might make sense to 
have home page be short, move current stuff to primer and then rest to 
documentation. Then, have one thing that links to everything.
DiD Good documentation but scattered. Not on entry point.
DD Move stuff from ERT home page to EARL home page. From there point to 
schema, model, graphics, etc.

DOM Test Suite
DiD So far we have relevant parts of DOM spec in our own DTD. Interface and 
method names - tests. We don't have any assertions in language. It has DOM 
constructs and programming constructs - for, scope, negation, etc. We don't 
have particular vocabulary for producing results. Perhaps a color-coded 
table. If use RDF could "this person states the test is in accordance 
w/spec" then crunch to generate actual result.
/* CMN joins */
DD Interactive tests?
DiD No. However, harness could generate EARL. Harness not the test suite.
CMN The harness is the place where you expect to use EARL. It uses pointer 
to test suite.
DiD Can generate code, compare to test suite. What is the connection to
EARL?
CMN "I pass this test and this one and this one" that is EARL.
DiD In addition need harness that's aware of tests, and can do 
transformation for you. Harness is EARL aware, run test, listen to result, 
generate EARL.
CMN Difference is instead of generating "pass or fail" you are generating
EARL.
DiD More than happy to provide meaningful results. Only problem is that DOM 
will not write harnesses. We will only provide tests and style sheets - 
that's the test suite.
CMN Who is writing harness?
DiD Implementors themselves.
DD Speaking with my QA hat, implementors have to write additional code?
CMN Have to have code to test DOM anyway.
DiD Make it simpler by giving tests judged correct. A manual job before 
test is released. Expected outcome.
CMN No requirement on creator test suite - they could do each by hand.
DiD right. I have no problem with that.
SP Use EARL to say that it passes tests suite?
DiD We do not make connection between spec and suite.
SP Conform to some id w/in the spec.
DiD Yes.
SP THen you can say that.
DiD Right. We can say that someone fails a test, and that that 
implementation does not support DOM spec. This is not spec conformance. 
Main question is, can we use EARL.
CMN I passed a test, what does that mean in a wider scope? What pieces of 
the scope do I need to recheck.
SP I generated an example this a.m.
DiD Pass or fail one test. Test suite not to cover whole spec.
SP Doesn't have to be, but certain pieces. Passing all doesn't mean DOM 
conformant. Any code that passes certain test case passes certain ID in 
spec. However, if it fails certain ID, then fails DOM compliance.
DiD Then can localize the error.
CMN Another important use case is same specs pointing to same test. E.g. 
"alt-text for everything" means 1.1 for WCAG. In U.S. 508, they have same 
requirement. Therefore if i meet the test case I meet x in rule set y, and 
a in rule set b.
SP I could do that tonight. In EARL, pass a test case. That gives 
conformance to various rule sets.
/* various discussion about granularity and making inferences */
DiD Dom spec not granular enough.
CMN Still need to read the spec. EARL is not magic bullet. Problem w/spec 
or the way the world is?
DiD When new tests added to framework, must be tied to spec. Also require 
that submitted tests must have expected outcome. therefore, have all the 
info necessary. The problem is enough info for me to do it, but not for a 
machine. Ask yourself a question, but won't get answer since DOM spec too 
high level. Have to ask the CML source.
SP Same problem as WCAG where not machine-readable. It's in prose.
DiD Right, DOM spec is XHTML, not granular enough.
SP Limited scope answers?
DiD Take collection of all similar tests and write assertion.
SP Right. Once done once, have it for next time. If do enough, in essence 
have machine-readable form.
DiD Collection of assertions, but never how related to spec. It's not 
machine readable.
SP Could not get inferences through all of the data. e.g. pass this one 
pass all others. But could say, to some subset of that. Get some useful
info.
DiD When I have a collection of tests, and you test "getNamedNode." you 
have 5 tests. You can compare tests. The relationships are expressed in 
machine readable. Attach to spec. Background color. Doesn't explain default 
values.
CMN We're talking about URIs. to describe relationship between 2 tests - 
have 2 URIs.
DiD How do you assert you want to do something w/the info that is pointed
to?
CMN An assumption of EARL.
DiD What if x needs to be a string?
CMN Part of test suite. Test suite says, "do this 5 times." You say pass or 
fail. If you look at CSS test suite. There are selector tests. You have to 
pass 5 or 6 of them. e.g. selector can't begin w/a number. you have 
incomplete result, it takes a lot of tests together to check for 
implementing one piece of spec. Have to be clear if sufficiently tested. 
One thing to do in harness is follow out the links. here's uri of what you 
got wrong.
DiD You could do more simply by checking pass/fail and go to link of test.
CMN In WCAG, go to each checkpoint.
DiD Main question - other people are writing harnesses, how do we convince 
them all to generate EARL?
CMN If you have more than one tool, they can take EARL input as well as 
EARL output.
Resolved: Will continue to discuss at next week's joint AU/ERT meeting: how 
to sell this to developers. What info can we pass to DiD to convince 
harness developers to make harnesses generate EARL.
Action CMN/WC: follow-up on AU/ERT discussion with DiD.

$Date: 2001/05/28 15:35:40 $ Wendy Chisholm

--
wendy a chisholm
world wide web consortium
web accessibility initiative
seattle, wa usa
tel: +1 206.706.5263
/--

Received on Monday, 28 May 2001 11:44:41 UTC