W3C

ERT WG

30 Nov 2005

Agenda

See also: IRC log

Attendees

Present
Johannes, CarlosV, Shadi, Sandor, Chris, CarlosI
Regrets
Nick, Charles
Chair
Shadi
Scribe
Sandor

Contents


HTTP in RDF

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2005Nov/0022

JK: added additional header properties
... divided into URI host port and absPath

SA: put stuff into usefull namespace
... now we have 5 different namespaces

JK: rfc2965 redefined cookie header

SA: what cookie is more deployd

JK: name is the same, value may be different

SA: netscape cookie part, actual description in commend

JK: in the commend described: this header is defined in rfc...

SA: should have pointer to the sources where it's based - like rdf:seeAlso
... cookies part: see what differences are in there - should forward to the annotea people, what we have come up with, give them a couple of tweaks

JK: agrees

SA: prop. next weeks, send out comment, edit working group note

CV: should have it before february

SA: 3-4 weeks should be enough to commend
... robust metadata from nick, unfortunately nick is not here :(((
... something that should be on top of EARL
... lot's of the checkpoints have dependecies, sometimes they're clear sometimes not
... table: if we hash the table, some cp apply to the table not outside - aslong as no changes outside the table happen nothing happens

Robust metadata

JK: more about how to implement the checking tool (easier for the programmer) - less for the EARL report
... if table does not change compare hashes ...

SA: many of the WCAG cp, can be described by what is the relationship to others
... e.g. image + description, can be hashed easily

JK: and the context does not change

SA: in many cases the context can be described by a hash
... should EARL express some of these persistency mechanisms?
... who is interessted working on this issue?

CV: what about the reliability of these descriptions - comparing docs/results
... use case: something cases in the page even if the xpath does not

SA: table: today manual eval, if we run test tomorrow can we reuse the result?
... need some kind of persistency, else we would have to run test again
... can be define priority levels on this issue?

JK: could be helpfull for manual checks

SA: some tools combine manual/automatic checks
... being able to reuse test results, is this useful?

CR: this is really important

JK: if there is a possibility to reduce the number of checks for manual evaluators -> this is good, does not make sense for automatic checks

SA: what is the priority on this for the ERT WG?

silence

SA: seems to be no key issue for the group

using locations with XPath

JK: if you don't have access to the the namespace mapping, no mapping unless you get an element / prefix namespace mapping
... no requirement for a docs to use prefixes
... if you want to locate elements, you normally take prefixes (map to URI)

SA: if the tool know how to map, it can figure out it anyway

JK: XPATH uses prefixes, these can be mapped, element uses namespaces, they may use prefixes but they are not required to

<scribe> ACTION: (For all) think about the XPATH issue, and solutions about it [recorded in http://www.w3.org/2005/11/30-er-minutes.html#action01]

SA: XML docs has doctype (e.g. XHTML), though the literal is in the same namespace

JK: several locs in the report, put it outside and used namespace class for the mapping

SA: for all again, use XPATH parsers and give feedback :)

Summary of Action Items

[NEW] ACTION: (For all) think about the XPATH issue, and solutions about it [recorded in http://www.w3.org/2005/11/30-er-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2005/12/01 21:52:59 $