ERT WG

(Continued) Proposed Changes to the EARL Schema

saz: tool and useragent folded into testSubject
... what is relationship of testSubject and WebContent

cmn: forcing subject to have an identifier brings problems

Zakim: q+

<chaals> niq: It is important to make sure that people don't confuse a URI used as an RDF identifier with a URI that is dereferenced.

thanks chaals:-)

<shadi> http://www.w3.org/WAI/ER/EARL10/schema.html#TestSubject

saz: date should be required property

cmn: there's an issue where date might be a point in time or a range of time

<chaals> CMN: DC date working group is in the process of defining dates as ranges (since all expressions of time cover a range) and providing best practices on defining an arbitrary range.

cmn: should have optional Title, Description

RESOLUTION: properties of testsubject - keep hasParts, ispartof, date; add optional title, description

saz: webcontent should be subclass of testsubject

cmn: more useful if webcontent not required to be testsubject
... rdf semantics allow webcontent to have testsubject properties without subclassing
... within an assertion, webcontent is testsubject

saz: needs written clarification

cmn: explanations of complexities need to go in the spec

saz: webcontent:date == testsubject:date

nk: http headers optional properties, with recommendations in spec

<Zakim> chaals, you wanted to argue for minimal restrictions *at this stage*

saz: need to identify subject in the case of conneg

cmn: http headers should be optional in webcontent

saz: agree we avoid excessive constraints
... separate HTP request and response

cmn: should consider non-HTTP webcontent such as SOAP

saz: clarify webcontent isn't just webpages

cmn: annotea has a vocabulary to describe HTTP headers
... properties (optional) are format, location, title, description

saz: title, description can inherit from testsubject when applicable
... properties of webcontent are Request, Response, format, location. Plus testsubject stuff

<chaals> RESOLUTION: WebContent can have any of location, format from DC, plus HTTP request and response (no range requirements) and drop HTTP header property from proposal

saz: this concludes first pass through schema

Zakim: close agenda item

Collect other outstanding issues

cmn: usingtool shouldn't be a property; should have a subclass of assertor for PersonUsingTool instead

<Zakim> chaals, you wanted to try and clear showstoppers

<shadi> http://www.w3.org/WAI/ER/EARL10/schema.html#Assertor

nk: question, could that be transitive

cmn: not necessary

saz: assertor is enum {Person, Tool, PersonUsingTool }

RESOLUTION: assertor is enum {Person, Tool, PersonUsingTool }

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2005Jun/0064.html

saz: tool can be assertor and/or testsubject. Need clear distinction
... rename tool class to software

cmn: note that this has implications on the restrictions in the assertor class

resolution: tool as assertor is called software

<chaals> RESOLUTION: Tool gets versioned out and replaced by "Software" which can be a subject, assertor, ...

saz: role of testcase?

cmn: eg to identify a WCAG guideline

<chaals> RESOLUTION: Note that TestCase as a class is something that we are only doing to fill a void...