09:43:17 <RRSAgent> RRSAgent has joined #bpwg
09:43:17 <RRSAgent> logging to http://www.w3.org/2007/04/02-bpwg-irc
09:43:20 <dom> RRSAgent, make log public
09:43:30 <dom> Meeting: mobileOK checker F2F in Dublin, day 1
09:44:14 <dom> Present: Shadi, Jo, Ruadhan, Dom
09:44:33 <dom> Regrets: Rolland, Abel, Nacho
09:44:38 <dom> Agenda: http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Mar/0050.html
09:44:50 <dom> Regrets+ Miguel
09:44:59 <dom> s/Rolland/Roland/
09:45:06 <dom> Chair: Jo
09:45:11 <dom> RRSAgent, draft minutes
09:45:11 <RRSAgent> I have made the request to generate http://www.w3.org/2007/04/02-bpwg-minutes.html dom
09:47:26 <shadi> shadi has joined #bpwg
09:59:11 <dom> s/checker/reference implementation/
09:59:13 <dom> RRSAgent, draft minutes
09:59:13 <RRSAgent> I have made the request to generate http://www.w3.org/2007/04/02-bpwg-minutes.html dom
09:59:52 <dom> s/reference implementation/checker/
10:00:08 <dom> s/mobileOK checker/mobileOK reference implementation/
10:00:10 <dom> RRSAgent, draft minutes
10:00:10 <RRSAgent> I have made the request to generate http://www.w3.org/2007/04/02-bpwg-minutes.html dom
10:14:30 <jo> jo has joined #bpwg
10:18:25 <dom> Agenda review: since shadi won't be available tomorrow pm, we'll try to get to the relevant items for shadi before then
10:18:54 <dom> We'll start at 8am tomorrow to cater for the people leaving early
10:19:06 <dom> Topic: document formats
10:19:32 <dom> -> http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Mar/0044.html Intermediate document revision
10:19:56 <dom> Shadi: HTTP in RDF in review until Apr 20
10:20:23 <dom> ... this note is based on a use case developed for EARL (Evaluation And Report Language), in Last Call
10:20:38 <dom> ... not everything is finalized
10:20:54 <dom> ... overall concept is that EARL captures the result (e.g. a given page failed a given test)
10:21:10 <dom> ... and sometimes you need to capture some specific HTTP interactions (e.g. content negotiation)
10:21:45 <dom> ... there is another use case: when happens when during an HTTP interaction, something occurs in the HTTP protocol that impacts the interaction
10:21:53 <dom> ... e.g. HTTP error, wrong HTTP header, etc
10:22:00 <dom> ... there are 2 issues we're looking at:
10:22:15 <dom> ... * the decomposition of headers into more elements (as requested by Jo)
10:22:35 <dom> ... but we still need to look at how the decomposed and composed version relate to one another
10:23:07 <dom> ... * the encapsulation of content inside RDF; e.g. if you want to record the body you got from the server 
10:23:26 <dom> ... how to record that byte sequence in RDF taking into account character encoding and XML limitations
10:23:56 <dom> ... also, you probably don't want to re-encode XML you already got from the server when the body is indeed xML
10:24:22 <dom> ... there is an algorithm on the table to deal with this
10:25:54 <dom> Jo: the comments I sent were sent on behalf of MTLD, but I think they reflect some of the concerns this group has had with HTTP-in-RDF
10:26:17 <dom> ... we need to be able to justify why a given analysis triggered a given result
10:26:52 <dom> ... This also means we may need to be able to have an exact copy of the request exchanges rather than just the structured version of the interaction in RDF
10:27:04 <dom> ... the same applies to the body 
10:27:41 <dom> ... we both need to work on a structured document (e.g. in XML), while also keep track of illformed documents
10:28:15 <dom> Dom: this relates to the encapsulation problem shadi was talking about
10:28:20 <dom> Jo: what kind of input do you need from us?
10:28:44 <dom> ... also, we need to have access to some of the XML data (xml declaration, doctype)
10:29:05 <dom> Shadi: regarding the transcript of the headers, we just need to add a property to record this
10:29:13 <dom> ... should be fairly simple to address
10:29:53 <dom> ... it indeed makes sense to record the original un-transformed set of requests/responses
10:30:04 <dom> ... for encapsulating the body, it is a bit different
10:30:28 <shadi> http://www.w3.org/TR/2007/WD-HTTP-in-RDF-20070323/#body
10:31:50 <dom> ... [shadi explains the algorithm as described by the diagram at http://www.w3.org/TR/2007/WD-HTTP-in-RDF-20070323/#body ]
10:33:01 <dom> [I wonder if MTOM is relevant here: http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/ ]
10:33:49 <dom> [or rather, XML-binary Optimized Packaging http://www.w3.org/TR/2005/REC-xop10-20050125/ ]
10:35:06 <dom> ... one option to get access to the XML declaration and doctypes data would be to add the relevant propoerties in the body representation
10:36:07 <dom> Jo: I think in our work, we'll end up with 2 representations of the body
10:36:17 <dom> ... the original transcript, and the structured version of it
10:36:54 <dom> ... there seems to be 3 ways to encode the body in what you describe
10:37:27 <dom> ... given we're likely always want to have some kind of XML version of the body (even if the original wasn't well-formed)
10:37:32 <dom> ... so that we can further process it
10:39:33 <dom> ... so I think we would have both the base64 version and the structured version based on fixes as needed, based on whatever flavours of tidying
10:41:24 <dom> ... so in our case, we'll always want to base64
10:41:29 <dom> ... why base64 btw?
10:41:40 <dom> shadi: base64 is the encoding used for the data: URI scheme?
10:41:45 <dom> s/scheme?/scheme/
10:42:49 <dom> dom: is this one or three properties?
10:43:09 <dom> shadi: right now, one, but we're now considering having 3, one of which would be "required"
10:43:17 <dom> ... (i.e. that you can always assume you'll get)
10:44:46 <dom> dom: probably worth checking what the web services guys have been doing too
10:45:05 <dom> ACTION: Shadi to get in touch with Yves on MTOM/XML-biniary Optimized Packaging
10:45:05 <trackbot> Sorry, couldn't find user - Shadi
10:45:22 <dom> trackbot, that's ok, we  expected it
10:46:40 <Ronan> Ronan has joined #bpwg
10:46:51 <dom> dom: at some point, we'll need to draw a line
10:47:03 <dom> ... e.g. consider HTTP as a blackbox
10:48:46 <dom> ... we may also want to consider developing our own RDF properties if our requirements go beyond the scope of HTTP-in-RDF
10:50:09 <dom> shadi: would also know what's your schedule is, to see how we accommodate your needs
10:51:05 <dom> jo: Sean seems to think there is less urgency in having a ref impl given that there already 2 reasonable implementations of mobileok
10:51:41 <dom> ... dotMobi has a preference in having a stable way, but don't want to have this takes too long either
10:51:50 <dom> s/having/having it developed in/
10:52:28 <dom> shadi: my impression is that this group wants to work pretty fast
10:52:45 <dom> ... we're trying to develop something forward-compatible
10:53:16 <dom> ... we're working with the W3C validator guys right now to get practical feedback on EARL
10:53:33 <dom> ... this also relates to UniCORN
10:53:53 <dom> ... it would be interesting to see how this checker will fit with the other W3C validators
10:54:45 <dom> ... this also relates on the discussion on procedural vs declarative / extensibility
10:54:57 <dom> s/relates on/relates to/
10:55:36 <dom> ... not sure about your timeline, but in our case, we're expecting quite a bit of feedback on our documents
10:55:47 <dom> ... feedback review finishg on Apr 20
10:56:02 <dom> ... We're hoping to go for CR by June for EARL
10:56:18 <dom> ... and hope to get another draft of HTTP-in-RDF before publishing it as a Note
10:57:22 <dom> Jo: re decomposition of data, there is also the question of normalization (e.g. no-cache in Pragma headers)
10:57:45 <dom> Shadi: we have looked at it briefly; some headers are case sensitive, some aren't
10:57:56 <dom> ... at this time, we've decided NOT to do any kind of normalization
10:58:29 <dom> Jo: it would be helpful to have a normalized version of the http headers for downstream processors
11:05:52 <dom> dom: I think one of the difficulties reside in separating the format representation from the processing
11:06:09 <dom> ... you'll probably want to create some conformance rules for a processor that would output HTTP-in-RDF
11:06:19 <dom> ... e.g. with one doing the full decomposition and normalization
11:07:49 <dom> ... normalization could include to output everything as lowercase for case-insensitive headers
11:08:25 <dom> shadi: will this group take a close look at the document and send comments?
11:08:37 <dom> jo: FWIW,  we're in a no-process land at this time
11:09:19 <dom> ... we'll be integrated in BPWG charter 2
11:09:20 <dom> dom: probably not a big deal
11:09:58 <dom> shadi: would be very useful to have comments from the group as a group
11:10:26 <dom> jo: esp as we'll be implementing this spec most likely
11:11:56 <dom> dom: FWIW, not sure we need to deal with implementing HTTP-in-RDF as a specific ref implementation
11:12:36 <dom> ... esp as this document in not going through CR
11:12:45 <dom> shadi: indeed, we probably don't need a formal implementation
11:13:00 <dom> ... as long as we can point to mobileOK as using this stuff
11:13:25 <dom> dom: I do think that we'll probably want to design our code so that hte HTTP-in-RDF can be easily re-used
11:13:29 <dom> s/hte/the/
11:13:49 <dom> shadi: also would be useful for implementing a WCAG 2.0 tester
11:21:31 <dom> q+ to ask if fieldName being both a URI resource and a literal is RDF OK
11:25:14 <dom> ACTION: shadi to look at the RDF design of http:fieldName being both a literal and a resource
11:25:14 <trackbot> Sorry, couldn't find user - shadi
11:25:21 <dom> RRSAgent, draft minutes
11:25:21 <RRSAgent> I have made the request to generate http://www.w3.org/2007/04/02-bpwg-minutes.html dom
11:30:30 <dom> Jo: can we parse this as XML rather than RDF?
11:30:53 <dom> Dom: I think the RDF output is "simple" enough that it may be possible to output the RDF in a less flexible fashing than what RDF allows
11:31:10 <dom> ... and make it parseable as XML constrained at the XML schema level
11:31:18 <dom> Shadi: we're hitting this problem with EARL too
11:31:30 <dom> ... we're not sure yet whether we'll be developing such a schema yet
11:31:38 <dom> ... although others have raised that concern
11:32:14 <dom> ... some of the difficulties relate to subclasses
11:32:43 <dom> ... we're hoping the RDF is simple enough at this time that an XML schema could work
11:33:17 <dom> Jo: I personnally don't think we'll have time to learn RDF in the timeframe of this project
11:33:22 <dom> ... I'm hoping we can rely on XML
11:33:29 <dom> Sean: that's what I have been assuming too
11:34:19 <srowen> srowen has joined #bpwg
11:34:21 <dom> RRSAgent, draft minutes
11:34:21 <RRSAgent> I have made the request to generate http://www.w3.org/2007/04/02-bpwg-minutes.html dom
11:50:52 <dom> Present+ Sean
11:54:46 <dom> Chair+ Sean
12:01:44 <jo> Topic: Milestones
12:01:49 <jo> scribenick: Jo
12:02:14 <jo> sean:we thought that there were ugenttimescales torendez-vouswith cadidate rec ofmobileOK
12:02:32 <jo> ...less urgency now as there are two implementations
12:03:00 <jo> ... no reason to slow down, though
12:03:01 <dom> s/ugentti/urgent ti/
12:03:08 <dom> s/vouswith/vous with/
12:03:11 <dom> s/ofmo/of mo/
12:03:28 <jo> ...tentative and intermediate milestones 
12:04:15 <jo> ... completion of framework, document formats etc
12:05:09 <dom> s/toren/to ren/
12:12:15 <jo> [sean draws on whiteboard]
12:30:17 <Zakim> Zakim has joined #bpwg
12:30:26 <dom> agenda+ logistics for this task force
12:34:50 <jo> dom: need to fix on weekly meeting date
12:37:40 <jo> sean: proposal 1:00 UTC, 2:00 UK, 3:00 CET 9:00 EDT
12:38:02 <dom> (on Tuesday, I assume)
12:38:07 <jo> ... need to check zakim availability plus convenience to other participants
12:38:14 <jo> ... on Thursday
12:38:59 <dom> sample of zakim calendar on Thusrdays: http://www.w3.org/Guide/1998/08/teleconference-calendar#D20070405
12:42:04 <jo> dom:should book it now or shall I wait?
12:42:36 <jo> sean:let's go ahead and change if nacho, abel can't make iit
12:44:29 <jo> sean: agree on design in principle in next two weeks
12:45:01 <jo> ... then deliverable no 1 (framework and 1 test) by May 1
12:46:38 <jo> ... modulo some of the implementation being temporary
12:52:18 <jo> Jo: how much time can we put on this
12:52:24 <jo> (discussion)
12:53:18 <jo> Jo: roughly 60 person hours a week
12:54:04 <jo> ... 25% time writing test cases
12:54:50 <jo> dom: what does the results document look like?
12:55:08 <jo> ... probably some EARl describing the expected output
12:55:42 <jo> ... should be OK for integration into JUNIT
12:56:26 <jo> sean: time will be burned on deciding (25%) revising framework, refactoring etc.
13:00:45 <jo> ... milestone 2, start of july for 20 tests
13:05:44 <jo> jo: need to do a pre release of all tests as we will want a period for 
13:05:57 <jo> ... perforamnce and bugs etc
13:06:10 <jo> dom: need some kind of ui thingy
13:06:18 <jo> ... to do testing
13:07:19 <jo> sean: by July we will have done 75% tests
13:07:34 <jo> ... so need more time for the remaining 25%
13:08:31 <jo> ... allow 8 weeks for the remaining
13:11:07 <jo> ... so start of september for all tests then 
13:11:59 <jo> .. milestone 3 is polish etc. by Sean's birthday on 17th Sept
13:13:06 <jo> s/../.../
13:14:30 <jo> jo: probably as far as we can go for now
13:14:44 <jo> ... need review of schedule as a standing agenda item
13:15:00 <jo> ... need to bring timetable in if we can
13:15:54 <jo> ... also need to write up timetable
13:16:34 <jo> _ACTION: Sean to write up timetable etc.
13:17:53 <dom> ACTION Sean: to write up timetable etc.
13:29:38 <dom> -> http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Apr/0003.html Sean's summary of the discussions on milestones/deliverables
13:33:57 <dom> RRSAgent, draft minutes
13:33:57 <RRSAgent> I have made the request to generate http://www.w3.org/2007/04/02-bpwg-minutes.html dom
13:35:57 <[1]Ronan> [1]Ronan has joined #bpwg
13:37:37 <dom> dom has joined #bpwg
13:38:13 <dom> s/Present: Shadi, Jo, Ruadhan, Dom/ScribeNick: Dom/
13:38:18 <dom> ScribeNick: Ronan
13:38:25 <jo> Topic: Validation
13:38:27 <dom> Present: Shadi, Jo, Ruadhan, Dom, Sean
13:38:31 <dom> RRSAgent, draft minutes
13:38:31 <RRSAgent> I have made the request to generate http://www.w3.org/2007/04/02-bpwg-minutes.html dom
13:40:13 <Ronan> jo: there is a question as to what we mean by validity
13:40:40 <Ronan> dom: we should use word conformant rather than valid
13:41:12 <Ronan> ... for xhtml valid means confirmant for for all others e.g. CSS we should not use word valid
13:42:22 <Ronan> jo: xhtml validity is clearly very important for this project
13:43:46 <Ronan> dom: xhtml validity is fairly well defined -- we can just pick some validator to start with, and then decide what to do if it is buggy
13:44:16 <Ronan> ... validating to DTDs is relatively straightforward .. should not see to many bugs
13:44:26 <Ronan> s/to/too/
13:44:52 <Ronan> jo: I'm more concerned about validity of gifs and jpegs
13:45:43 <dom> -> http://www.w3.org/Graphics/GIF/spec-gif89a.txt GIF specification
13:45:59 <Ronan> .. We will be using implementations that we don't know the details of e.g. standard Java tools for reading jpegs
13:46:22 <Ronan> .. There are assumptions embedded in these that we don't fully understand
13:47:42 <Ronan> dom: All s/w implementations will have bigs and undefined behaviours. The various libraries that we use may not have the detail that we need
13:49:32 <Ronan> jo: We may need to make our claims based on something else .. we use X validator to check validity
13:49:55 <Ronan> .. can we mix & match validity claims
13:50:08 <Ronan> .. based on the underlying libraries etc
13:50:29 <Ronan> .. Semantics of claim may need to be rich enough to embed this information in claims
13:51:25 <Ronan> dom: Unless there are bugs in implementation or standard there is no room for disagreement
13:52:14 <Ronan> jo: agrees but specs may not have validity clauses in them
13:53:27 <Ronan> dom: If checker is used in legal framework there may be problems -- but doesn't think it is our job to address all bugs in underlying s/w -- we can have disclaimer for this
13:53:51 <Ronan> jo: DotMobi may be putting itself in dangerous legal position
13:59:24 <Ronan> Ronan has joined #bpwg
13:59:48 <Ronan> jo: claims should be based on a chain of trust
14:00:12 <Ronan> .. checker should allow people to pick which validator they wish to use
14:00:22 <Ronan> dom: thinks it too early to get into this depth
14:01:15 <Ronan> jo: the input to the check is not just the doc under test -- it should include (say) a reference to some validity checker for some part of the test
14:02:09 <Ronan> dom: value of tool could be reduced if you allow people this flexibility, plus it is less pragmatic
14:02:39 <Ronan> jo: allowing this configurability would make tool more useful
14:03:02 <Ronan> .. uniformity of results cannot be guaranteed in any case -- temporal changes etc
14:03:22 <Ronan> dom: still thinks it should not be a requirement
14:03:55 <Ronan> sean: thinks that this won't be a problem in practice -- the libraries that we actually use are likely to be more liberal than the phone s/w
14:04:42 <Ronan> .. but it certainly doesn't hurt to report on the libraries that were used
14:05:09 <Ronan> .. but allowing substitutions of validators seems to be solving a problem that we have
14:05:45 <Ronan> jo: this is worth thinking about up front because if it turns out to be a problem, it could be a very serious problem
14:06:27 <Ronan> sean: taking a real example if xhtml, people don't really seem to be confused about validity
14:06:42 <Ronan> jo: at a minimum we should report on versions of libraries etc
14:07:22 <Ronan> .. would like it to be at least possible to swop in other validators
14:07:35 <Ronan> sean: isn't the fact that this is open source enough?
14:09:14 <Ronan> dom: this effect can be achieved in other ways - wrapping an existing service such that it can be built in -- doesn't need to be designed in from start
14:10:18 <Ronan> jo: audit trail is very important part of a claim
14:12:37 <Ronan> shadi: what exactly is a checker doing -- is it formally described?
14:12:59 <Ronan> dom: not formally described as such -- it simply performs each of the 26 checks in mOK Basic
14:13:18 <Ronan> .. the open issue is to what extent the audit trail is part of the result
14:14:59 <Ronan> jo: an analogy -- road worthiness certs (emissions etc) depend on who issued them -- this is just part of life
14:15:34 <Ronan> ruadhan: might be easier just to pick a validator and be open about versions
14:18:30 <Ronan> ronan: agrees
14:19:09 <Ronan> ronan: unless code is really bad it should be be easy enough to change implementations in any case
14:19:43 <Ronan> jo: outcome seems to be that we should *weakly* support the idea of changeable implementations of tests
14:21:10 <dom> Topic: Declarative vs Procedural - aka Jo vs Sean
14:27:43 <dom> -> http://hul.harvard.edu/jhove/ JHOVE - JSTOR/Harvard Object Validation Environment
14:28:01 <dom> Jo: JHOVE does validation of various file formats, including JPEG and  GIF
14:28:36 <dom> "The initial release of JHOVE includes modules for arbitrary byte streams, ASCII and UTF-8 encoded text, GIF, JPEG2000, and JPEG, and TIFF images, AIFF and WAVE audio, PDF, HTML, and XML; and text and XML output handlers."
14:30:18 <dom> -> http://hul.harvard.edu/jhove/gif-hul.html GIF module in JHOVE
14:30:31 <dom> -> http://hul.harvard.edu/jhove/jpeg-hul.html JPEG module in JHOVE
14:31:41 <dom> dom: unclear on what part of which specs their wf/validity criteria are based
14:31:58 <shadi> shadi has joined #bpwg
14:40:11 <Ronan> Background: Ideally pre-processed output could be sent through an XSLT to produce the EARL result
14:40:21 <Ronan> .. assuming no performance issues with this
14:41:12 <Ronan> .. Auditability and extensibility are main reasons for this
14:42:07 <Ronan> .. Anything that can't be done with xpatch etc will have to be done as part of pre-processing
14:42:19 <Ronan> ..Example of this might be UTF-8 testing
14:42:23 <dom> s/xpatch/xpath/
14:43:06 <Ronan> .. The hard line on this is that anything that can't be done with XSLT, XPATH etc has to be done in pre-processing
14:43:22 <Ronan> Sean: XPATH is for looking for things in docs rather than anything else
14:44:32 <Ronan> Dom: some of the extensions that you might want to do would require deep analysis of input e.g. JPEG testing
14:44:53 <Ronan> Sean: .. so result doc should include more information than you need for the basic tests
14:45:43 <Ronan> Jo: yes, so result doc should include original payload to enable this extensibility
14:46:36 <Ronan> Shadi: extensibility can also include translation to other human languages
14:47:55 <Ronan> .. XSLT might be enough to translate text to a different human langauge
14:48:19 <Ronan> Sean: this implies that the original doc must be well formed also
14:49:13 <Ronan> Sean: Jo is proposing that there is some process that emits tests results alongside a lot of other information
14:49:30 <Ronan> .. everything that we know about the doc
14:49:34 <Ronan> Jo: agrees
14:50:47 <Ronan> Jo: is in favour of using an approach that allows all tests that actually require code to be done up front
14:51:20 <Ronan> Sean: seems like collecting all required information up front
14:51:33 <Ronan> Jo: there are some things that you just have to do in code
14:52:18 <Ronan> Dom: we will also be interested in why something is not valid -- not just a true/false
14:52:49 <Ronan> .. some kind of key that can be associated with human readable document
14:54:26 <Ronan> Dom: so how does this impact the development of this project? Can we still postpone the harder tests until the end?
14:55:43 <Ronan> Sean: there are Java methods for internationalization of messages
14:56:14 <Ronan> Jo: but people may not have access to Java compilers etc
15:00:22 <Ronan> Jo: shows example of XSL
15:02:44 <Ronan> .. to show how XSL can be used to capture test results from a document
15:03:30 <Ronan> Dom: in this case the XSL is doing some of the analsys as well as the presentation .. not a very clean model
15:04:01 <Ronan> .. this division of intelligence makes bug fixing smart
15:04:14 <Ronan> .. you loose the benefits of modularization
15:06:43 <Ronan> .. intelligence should not be built into this layer -- should be limited to lighter tasks
15:08:03 <Ronan> Jo: having more intelligence in the XSL means that the test doc (the intermediate doc) is richer
15:09:18 <Ronan> Dom, Sean: There should be a line somewhere -- how much processing should be done up front
15:10:26 <Ronan> Jo: if the intermediate doc is not rich, you preclude the opportunity to decorate the original document -- this is a good way to add value
15:12:47 <Ronan> Dom: we could analyse the 26 tests and see how many of them lend themselves to pre-processing or not
15:14:51 <Ronan> Why not do both? Include both a summary and the extra detail in the intermediate doc
15:18:02 <Ronan> Jo: it may make sense to do the validity checking at the same time as the pre-processing
15:20:25 <Ronan> Sean: how strong is the case for extensibility?
15:20:45 <Ronan> .. Is this our goal?
15:21:43 <Ronan> Is this a reference implemention or a software building block?
15:24:04 <Ronan> Sean: it seems like there are 2 things here: 1) go get doc and do some analysis on it and 2) report on this
15:26:33 <Ronan> Dom: thinks that base implementation should do only minimal digest of tests
15:27:21 <Ronan> Jo: we need to think about this
15:28:14 <Ronan> .. one school of thought is that we add no extra information to the result
15:28:50 <Ronan> .. other schools that we add lots of data -- perhaps everything we know -- into the result doc
15:30:25 <Ronan> .. for value-add for other applications
15:36:10 <Ronan> Will revisit this discussion tomorrow
15:37:33 <RRSAgent> I have made the request to generate http://www.w3.org/2007/04/02-bpwg-minutes.html dom
15:38:14 <dom> Topic: Results doc format
15:39:08 <dom> -> http://www.w3.org/TR/2007/WD-EARL10-Schema-20070323/ Evaluation and Report Language (EARL) 1.0 Schema, W3C Working Draft 23 March 2007
15:39:19 <dom> -> http://www.w3.org/TR/2007/WD-EARL10-Schema-20070323/#outcomevalue Outcome value in EARL
15:39:50 <shadi> http://www.w3.org/TR/2007/WD-EARL10-Schema-20070323/#testresult
15:40:17 <shadi> earl:info
15:40:24 <dom> -> http://www.w3.org/TR/2007/WD-EARL10-Schema-20070323/#testresult "2.6. Test Result" in EARL, with earl:info property
15:42:59 <srowen> srowen has joined #bpwg
15:43:17 <dom> -> http://www.w3.org/TR/2007/WD-EARL10-Schema-20070323/#testresult "2.6. Test Result" in EARL, with earl:info property
15:49:04 <Ronan> Discussion about EARL's suitability to mOK
15:49:26 <Ronan> EARL does not have ability to group tests -- which is probably necessary for mOK
15:50:24 <Ronan> Jo: making the tests more atomic is not necessarily a solution for this
15:50:48 <Ronan> Sean: We could use the info elements to hold extra information
15:51:03 <Ronan> Dom: We should not be relying on human readable stuff
15:52:40 <Ronan> Sean: we can add an extension to the EARL RDF vocabulary that will allow us to express mOK tests
15:52:59 <Ronan> .. the vocabulary should accomodate this
15:53:40 <Ronan> Sean: to what extent does EARL let you describe your test implementation?
15:54:03 <Ronan> Shadi: there is a compound assert element that can be used for this purpose
15:55:32 <dom> ACTION Sean: to draft comments on EARL 1.0
15:57:54 <Ronan> Discussion about how to represent XML etc in EARL
15:58:11 <Ronan> There is no defined way to do this
15:59:05 <Ronan> Jo: we should have a schema for this so that XPATH can be used
16:00:18 <Ronan> Jo: would be nice if all implementations used this schema - not just ours
16:01:09 <Ronan> Jo: we need to take our example of the result document much further than it already is
16:02:37 <Ronan> Dom: we could look at the dotMobi XML mOK output and try to transform it to EARL
16:02:39 <dom> ACTION Jo: to transform an instance of Mr Dev output in our expected EARL output format
16:03:22 <dom> shadi: EARL is perfect
16:03:28 <dom> ... don't you dare send comments
16:04:08 <shadi> clarification: this is of course a joke :)
16:06:49 <dom> RRSAgent, draft minutes
16:06:49 <RRSAgent> I have made the request to generate http://www.w3.org/2007/04/02-bpwg-minutes.html dom
16:11:24 <dom> Zakim, bye
16:11:24 <Zakim> Zakim has left #bpwg
16:12:08 <jo> tomorrow - zoom in on intermediate doc and the design doc and code, maybe, process ownership etc. 
16:12:12 <dom> RRSAgent, draft minutes
16:12:12 <RRSAgent> I have made the request to generate http://www.w3.org/2007/04/02-bpwg-minutes.html dom
16:12:15 <dom> RRSAgent, bye
16:12:15 <RRSAgent> I see 5 open action items saved in http://www.w3.org/2007/04/02-bpwg-actions.rdf :
16:12:15 <RRSAgent> ACTION: Shadi to get in touch with Yves on MTOM/XML-biniary Optimized Packaging [1]
16:12:15 <RRSAgent>   recorded in http://www.w3.org/2007/04/02-bpwg-irc#T10-45-05
16:12:15 <RRSAgent> ACTION: shadi to look at the RDF design of http:fieldName being both a literal and a resource [2]
16:12:15 <RRSAgent>   recorded in http://www.w3.org/2007/04/02-bpwg-irc#T11-25-14
16:12:15 <RRSAgent> ACTION: Sean to to write up timetable etc. [3]
16:12:15 <RRSAgent>   recorded in http://www.w3.org/2007/04/02-bpwg-irc#T13-17-53
16:12:15 <RRSAgent> ACTION: Sean to to draft comments on EARL 1.0 [4]
16:12:15 <RRSAgent>   recorded in http://www.w3.org/2007/04/02-bpwg-irc#T15-55-32
16:12:15 <RRSAgent> ACTION: Jo to to transform an instance of Mr Dev output in our expected EARL output format [5]
16:12:15 <RRSAgent>   recorded in http://www.w3.org/2007/04/02-bpwg-irc#T16-02-39