See also: IRC log
http://lists.w3.org/Archives/Public/public-wai-ert/2007Apr/0014.html
JK: there are problems with data URI scheme
... for non-text/plain/US_ASCII stuff data URI must include mediaType; so
data URI is not just a representation of the content, but content + media
type, which is already in the Content-Type header
... proposal: "new" property for non-text stuff (base64Content); we already
had this before we talked about data URI scheme
CI: Where there problems with the base64Content property? Why did we consider data URI?
JK: don't know
CI: base64Content property would be ok for me, let's ask others (who remember)
JK: ISSUE-011 editorial issue
CI: ISSUE-012/-013 maybe too much "noise" in the schema, but generally no problem
JK: ISSUE-014/-015
http://lists.w3.org/Archives/Public/public-wai-ert/2007Mar/0108.html
JK: no solution for ISSUE-014
... Eric has a solution for 015
CI: it's sort of ugly, but it works
JK: I could try to implement the proposal
... issues 016/018/019 about mixing OWL and RDFS -> discuss these in
connection with EARL schema
... any new thoughts about inconsistency and complexity?
CI: I prefer current approach
JK: issue 007 is predefined value "accept"
equivalent to literal "accept" or literal "Accept"?
... Should applications ignore literals when there is a predefined value?
Should they treat the literal as equivalent?
CI: literals and predefined values (same name: "accept") are not equivalent
JK: issue 006
... e.g.: Accept: application/xhtml+xml, text/html
... literal field value "application/xhtml+xml, text/html"
... or you could split this into several HeaderElements
CI: always issues with upper-/lower-case, maybe we should say, both solutions are not equivalent