See also: IRC log
RESOLUTION: Revised EARL schema accepted subject to 24 hours further scrutiny time
saz: Location property needs to be a bag?
cmn: likes a bag
nrk: we need to define the bag but there seems to be little love for it in general, so maybe we should go with the same approach as we did for Assertor and make explicit classes and properties: several instances of an error, or several descriptions of an instance?
saz: clarifies, assertion may have bag of locations, but location may have more than one part
<chaals> [example of a compound location - validity problem where a n element should have been closed, and you point to the starting element in one place, and where it should be closed somewhere else]
nrk: compond locations have more structure than a bag - should leave structure to implementors
saz/nrk: think about primary and subsidiary [parts of] location?
cmn: just several parts
... don't necessarily want primary/subsidiary
saz: just use one location property, defer refinement discussion
saz: Location variants: line/col, offset byte/char, xpointer
cmn: Property should be open
<chaals> [for CSS selectors, in a tag soup document you can use something like img[src=fred.jpg] and it has well-defined meaning, which isn't the case for Xpath/Xpointer]
saz: we can agree on a list of predefined location types
cmn: need to clarify the fine detail: count from 0 or 1; accept all forms of lineend, ??
<Zakim> chaals, you wanted to note that there are some layout-type problems, awhere the description is going to be in terms of a direction on the screen.
<shadi> list of candidates are: line/col, offset, CSS selector, XPath, XPointer, text description, fuzzy pointers
cmn: character offsets may have normalisation issues
<chaals> [line/col can be a range, as well as a blank]
<chaals> [location in a visual presentation, and time information in a dynamic medium, are two issues. Both of these can be represented using XML technologies and making Xpointers, but this is not always the easierst approach]
<chaals> Oh. dropped connection. system-wide :-(
<chaals> We ahve a rpoposal that I put during the face to face, which is still the proposal I would put next week.
cmn via saz: three ways of testing - human, machine, derivation
<chaals> If you make a claim based on other claims (e.g. I can see some collection of claims that amounts to claims for each checkpoint of WCAG, and you have a rule that says WCAG triple-A conformance is just conformance to each checkpoint of WCAG, then you can say mode=heuristic that the subject meets WCAG ltriple-A without doing any actual testing.
<chaals> It would be useful to be able to say what you base such a claim on.
nrk: this sounds like the auto/manual/heuristic property of Assertor
<chaals> For example, there may be conflicting claims about some checkpoints, or you may only want to trust claims based on checkpoints from some particular assertors.
saz: maybe could be property of testcase
<chaals> so the idea is to be able to say that in making some assertion, which is done as mode=heuristic, you used some given collection of assertions, and of rules.
saz: discussion needs chaals on voice
<chaals> cannot be a property of testcase, because you cannot hang the particular assertions off the testcase.
saz: next telecon sept 20th
<chaals> could be a property of Assertion, or of result though.
<chaals> Chaals sends regrets for 20th.