ERT WG -- 20 Sep 2005

Evidence Class

SAZ: Evidence class, we've had some discussion on it before, see the minutes in the agenda email
... Basic idea is that some assertions are purely based on other assertions rather than on tests
... checkpoint 1.1 from WCAG you have to do several small tests, and based on the success of them all you can make an assertion on the overall checkpoint
... Or because one fails, the checkpoint fails.

<niq> Zakim: +q to ask where earl:evidence lives

SAZ: Assertions based on other Assertions
... evidence is based of the assertions and a ruleset which describes the result.
... ruleSet is a can of worms which could be scary for us to introduce
... No discussion yet on where it lives, either in the assertion or in the testcase

NK: Where should it live? It seems to be what we've got called a Heuristic test, belonging in test case and is part of test case which makes evidence a poor name

<CarlosI> problems with the phone, working on it...

SAZ: evidence would make testMode redundant

<niq> question is whether the proposal is to match [something] in testcase with [evidence] in assertion

SAZ: evidence is a misleading term perhaps.

NK: testCase says "such and such should be met" and the result says "yes/no/etc"
... If I have a tool that can't test validation, we can say that it meets such and such if it also validates.

JL: ruleSet is just another part of test, whereas evidence is valid for a result.

NK: Do we need an evidenceOf ?

SAZ: ruleSet can be taken out from evidence, as it's a testSubject

NK: tough without chaals here

SAZ: mine and JL's opinion we remove ruleSet

NK: me too!

SAZ: any concerns on removing ruleset?

ALL: silence

SAZ: Where should evidence go?
... Is evidence of a result or an assertion?

JL: Seems to be the result for me.

NK: could be about either assertion or result

SAZ: how is it different between compound and single assertions?

NK: We could have seperate evidence on seperate parts of the whole.

SAZ: evidence is a bad name, maybe earl:references or something is good to relate other things...

NK: It doesn't really matter what we call it to where it goes.

<niq> zigackly

SAZ: references/evidence need to be for something.

JL: not anti it being anywhere but aren't too sure exactly what it would be pointing to.

CR: no strong opinions where...

CH: ditto

SAZ: Not result, assertion
... The assertion points to the other things that it's considered to arrive the result, the testCase, the subject, and other assertions.
... the 2 options are in the assertion or result, with Assertion being the strong favourite.
... Does everyone agree it makes sense to have an earl:evidence

JL: sounds good to me, only where it should go is open until I've seen it in action.

SAZ: Yep need to start looking how to query it - everyone go look!

<niq> then we can replace results with earl;verdict :-)

SAZ: Anything else on this, especially concerns?

<niq> yow, identity crisis!

Assertor Class

SAZ: YAY! Earl Schema was published
... Assertor class, lots of open issues
... list of possible properties aren't complete, line numbers etc. all need to go in, but the overall location class is the first step
... either Simple or Complex Location

NK: Zero or more of the various properties ?
... If we have xpath and line/column and fuzzy etc. it's a bit odd to call it a single Locator
... you really need both line and column (rather than just a column) to identify something, it's part of a compound line/column element.

SAZ: if we have singleLocator it makes compoundLocator rather redundant - could give a maximum cardinality on it.

NK: We have 2 things, where we want to say, this, this and that don't have an ALT attribute.
... and we have another which is pointing to multiple things which are related

is case 2 - e.g. pointing to 2 links that don't have space between ?

<shadi> earl:Location (type simpleLocator) earl:XPath

SAZ: Case 1 - a simple locator pointing to a missing ALT, which has an earl:XPath

<niq> xpath is also multivalued

<shadi> <earl:XPath>value</earl:XPath>

SAZ: this is a singleLocator with the XPath as a child of Location
... You could have several of these for each image without an ALT for example
... Alternatively, you can have a compoundLocator

<niq> heh

<shadi> <earl:XPath>instance 1</earl:XPath>

<shadi> <earl:XPath>instance 2</earl:XPath>

<shadi> <earl:XPath>instance 3</earl:XPath>

SAZ: either we could repeat XPath 3 times, or 3 times the location classes

<shadi> <earl:XPath>trigger 1</earl:XPath>

<shadi> <earl:XPath>trigger 2</earl:XPath>

<shadi> <earl:XPath>trigger 3</earl:XPath>

<niq> yeah, 3xXpath looks like a sensible contraction there, provided they don't get confused

SAZ: Within the location there are locator property which makes it a compoundLocator to distinguish the different types of XPath instances/triggers

NK: an earl:Location with lots of locators inside deals with the compound case, that seems a little difficult to use

SAZ: What do you want to say?

NK: I'm not sure, that this allows me to say the relationships between the triggers.
... the last one seems difficult to use.
... Use case is pointing to e.g 2 links and saying there's no use case.

er.. scratch that

JL: Use case is pointing to 2 links and saying there's no whitespace between them e.g.
... but is the relationship between the different parts clear so that tools can make sense of the different parts.

NK: It depends on the testcase what the relationship between the elements are.

SAZ: Do we need to describe the relationship between the locator elements?
... I don't think it does, as I think a consumer of the earl can present the points that the test fail on, without needing to have it expressed in the earl itself.
... Nick send some more explicit comments on the earl:locator Location compound stituation.

ERT WG

20 Sep 2005

Attendees

Contents

Evidence Class

Assertor Class

Summary of Action Items