See also: IRC log
<ChrisR> SAZ: summary of issue - byte offset or char offset
<ChrisR> JK: has 2 issues...
<ChrisR> 1) byte offset
<ChrisR> JK: 2) problem with unicode
<ChrisR> JL: agrees with JK, need both
<niq> char offsets fall down if there's an encoding error in a text source. Need byte offsets to be allowed.
<ChrisR> NIQ: yep, need both types of offsets
<niq> text text [badbytes] more text *
<niq> the number of chars in [badbytes] is undefined.
<niq> so the char offset of * is not well-defined
<niq> but the byte offset of * works just fine
I think Johannes could be able to do and proably should. but it doesn't hurt EARL Pointers to have both
<ChrisR> NIQ: problem can occur with text encoding errors or if any bytes are unencoded, this is real world problem
<ChrisR> SAZ: suggests that scheme could be developed for snippets or bytes/chars, example binary files such as images or audio files
<ChrisR> JL: currently don't have anything to point to binary files, should be developed
<ChrisR> (general agreement that both byte and char offset needed but more discussion needed)
<ChrisR> ACTION: JL will review with feedback [recorded in http://www.w3.org/2006/04/26-er-minutes.html#action01]
<shadi> ACTION: jim to refine current snippets proposal [recorded in http://www.w3.org/2006/04/26-er-minutes.html#action02]
SAZ: Last call, we had proposal from Carlos for groups of webcontent
SAZ: Do we want blanket states by earl and use
wildcards rather than specifying all
... Could be verbose if you list all, but it's very accurate
... Alternatively it allows us to make general statements about entire sites, related to the Content Labelling Group
JL: Wildcards don't give us any more
expressability, as we can extend EARL to have a new TestSUbject that covers
are groups and can be expressed as we want.
... Wildcards are more complicated and make things harder for people
<drooks> sorry but my skype is really playing up. will have to continue via irc
SAZ: Would you say that EARL is a general reporting language for making statements exactly what is tested, rather than for making blanket statements?
SAZ: Nick we can't hear you!
JK: I like the idea of having specifically for reporting results of tests and what I tested is the resource, and some more resources etc. saying exactly what I tested
SAZ: Is Verbosity a problem for your tools?
JK: Not everything is necessary to be recorded every time, only if necessary, so a report doesn't need to be huge
CR: I don't think we should allow blanket statements without refering back to something
SAZ: Are we saying the blanket statement is not a role for EARL?
CR: blanket statements could still be made, but
you need to refer back to something
... You could say "this site passes" in EARL
SAZ: But you need to extend EARL currently to make statements about entire sites
JK: If you make a statement about a list of pages, then you've not made a statement about the whole site
CR: Could you not say that "these are all the pages that make up the site"
JK: Not with the EARL Vocabulary
... There is hasPart etc.
<niq> we already have multi-level testsubject
<niq> e.g page/snippet
<niq> whole site is just another level
CI: We all have different ideas of what a
report is and different use cases
... lots of users just care about different groups, e.g. site, rather than individual pages
... So if we want a complete report language, we need to cover that
SAZ: Do we need to be able to say site X is valid and points to an EARL report, does EARL have to be able to fulfil both
CI: We should give our requirements to the Content Labelling group if we don't do it
<ChrisR> SAZ: proposal: Seperate conformance claim from groups of pages.
<ChrisR> SAZ: can be done in RDF but may not be easy to parse
<ChrisR> SAZ: need to describe groups of pages (regular expressions for domain names) sort of thing
<ChrisR> SAZ: using EARL for blanket statements does not seem to have much support in group