3 May 2006


See also: IRC log


Shadi, David, Johannes, CarlosV, Chris, CarlosI, Nick


EARL snippets proposal

<niq> saz: encoding (raw or base64) as separate elements, or properties of a content element

<niq> niq: like the flexibility of the RFC822 approach

<niq> niq: MIME is tried-and-tested

JK: what we need is a transformation method to transform the bytes we got over the network into characters; and I think base64 is enough for this task
... I would like to use this approach in HTTP-in-RDF as well
... if EARL writing tool can use whatever transformation method it likes, EARL reading tool will have to implement several as well

SAZ: generic approach is more flexible and future-proof


<JibberJim> generic approach is unneccesarilly solving problems we don't really need

<niq> You say "text" vs "base64". But "text" isn't really well-specified, at least outside of plain ascii

<niq> I'm OK with non-generic approach (though prefer generic) provided it's well-specified

SAZ: others?

CR: still thinking

CV: + for text/base64

CI: + text/base64

Resolution: two content properties, one for text, one for binary
... binary content is base64-encoded

<Zakim> niq, you wanted to say Johannes is right, but that's not the whole story

JK: we don't need to report a specific character encoding for textContent

<niq> Snippets included from a document must be converted from the character encoding of a document snippeted to the charset of the EARL report. Tools traditionally get that wrong (c.f. mail-over-the-web systems)

<niq> grrr

JK: some discussion about characters, bytes, character encodings ...

<shadi> saz: 2 possibilities: 1. use the encoding of the original EARL report which is the simplest and easiest approach

<shadi> saz: 2. use the encoding of the remote Web resource, in which case we would need to record this encoding as well (and thus add complexity to processors and parsers)

<niq> 2. only works if all snippets are CDATA

JK: the only connection between character encoding used for the EARL report and the character encoding used to create the character from the resource byte stream is that there must be a mapping for the characters to be put into the snippet

CV: #2 doesn't make sense

Resolution: people agree with JohannesK that there is no problem with characters in text snippets

WCAG 2.0 Last Call

SAZ: any objections that ERT WG should not review WCAG 2.0?

CV: have problem with deadline

SAZ: everyone is welcome to comment
... we need to review from test tool implementor's POV
... we should focus on the "Understanding" doc
... expect comments on ERT mailing list
... I want a group's position

<scribe> ACTION: everyone to read the "Understanding WCAG 2.0" document until next week's meeting [recorded in http://www.w3.org/2006/05/03-er-minutes.html#action01]

SAZ: send comments to ERT list

Summary of Action Items

[NEW] ACTION: everyone to read the "Understanding WCAG 2.0" document until next week's meeting [recorded in http://www.w3.org/2006/05/03-er-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/05/03 15:58:26 $