See also: IRC log
<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
NK: ACK to SAZ
<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
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