See also: IRC log
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2007Aug/0012
SAZ: comments related to Content in EARL and HTTP-in-RDF summarized
CI: when http:Content came in?
... AFAIK is not part of HTTP and so I think is not a good idea to have it at
HTTP-in-RDF
SAZ: AFAIR the idea came in at last F2F
... probably it was named Content instead of Body because the property was
already body
... one of the possible solutions is to get the Content "concept" outside of
both into a new document and reuse from there as CarlosV argued
<shadi> http:Body subClassOf rfc822:Content
SAZ: The first question is, should we drop
earl:Content or not?
... does anybody fell we need to keep it?
CI: so, the idea is to drop earl:Content and use TestSubject instead to point to a Content class defined anywhere?
<shadi> <earl:testsubject rdf:resource="content01"/>
SAZ: Yes
<shadi> <earl:Content rdf:ID="content01">
<shadi> http://www.w3.org/TR/EARL10-Schema/#content
<shadi> example 13
<shadi> <earl:context rdf:resource="#httpRequest"/>
SAZ: earl:Content seems to be a not necessary in-between class
<shadi> http://www.w3.org/TR/HTTP-in-RDF/#body
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2007Aug/0003.html
SAZ: http:Content is defined in quite a generic
way now and could be reused
... if http:Content is generic enough earl:Content becomes redundant
... the question then is if going on with the http:Content is a "clean"
solution
... also need to think how to separate it: a new section, a new
document...
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2007Jul/0052
SAZ: Seems that there is a use case for an
"inferred" result
... some people don't like the term itself
<shadi> http://www.w3.org/TR/EARL10-Schema/#testmode
CI: composition of tests is more a test case
definition question, not a result one
... for me the best solution is not to have a inferred result type and
specify rules on how to compose different results
... e.g. automatic+automatic=automatic and automatic+manual=manual
... need to think about the possible combinations to see if could be
tricky
RR: you'll lose the details, how many manual, how many automatic...
SAZ: you will still have the details in other results if you want
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2007Jul/0042
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2007Jul/0049
CI: don't like the idea of PointerGroup not
beeing a Pointer subclass
... more difficult to reuse outside EARL
... no difference between Char and Byte Offsets
SAZ: more flexible
CI: could update the document with the changes
SAZ: would like to focus on the overall model