See also: IRC log
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
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
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
... 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?
SA: seems to be no key issue for the group
JK: if you don't have access to the the
namespace mapping, no mapping unless you get an element / prefix namespace
... 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 :)