IRC log of bpwg on 2007-04-02

Timestamps are in UTC.

09:43:17 [RRSAgent]
RRSAgent has joined #bpwg
09:43:17 [RRSAgent]
logging to
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]
09:44:50 [dom]
Regrets+ Miguel
09:44:59 [dom]
09:45:06 [dom]
Chair: Jo
09:45:11 [dom]
RRSAgent, draft minutes
09:45:11 [RRSAgent]
I have made the request to generate 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 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 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]
-> 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]
10:31:50 [dom]
... [shadi explains the algorithm as described by the diagram at ]
10:33:01 [dom]
[I wonder if MTOM is relevant here: ]
10:33:49 [dom]
[or rather, XML-binary Optimized Packaging ]
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]
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]
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 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 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:
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]
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]
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]
-> 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 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 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]
13:44:52 [Ronan]
jo: I'm more concerned about validity of gifs and jpegs
13:45:43 [dom]
-> 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]
-> 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]
-> GIF module in JHOVE
14:30:31 [dom]
-> 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]
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: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 dom
15:38:14 [dom]
Topic: Results doc format
15:39:08 [dom]
-> Evaluation and Report Language (EARL) 1.0 Schema, W3C Working Draft 23 March 2007
15:39:19 [dom]
-> Outcome value in EARL
15:39:50 [shadi]
15:40:17 [shadi]
15:40:24 [dom]
-> "2.6. Test Result" in EARL, with earl:info property
15:42:59 [srowen]
srowen has joined #bpwg
15:43:17 [dom]
-> "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 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 dom
16:12:15 [dom]
RRSAgent, bye
16:12:15 [RRSAgent]
I see 5 open action items saved in :
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
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
16:12:15 [RRSAgent]
ACTION: Sean to to write up timetable etc. [3]
16:12:15 [RRSAgent]
recorded in
16:12:15 [RRSAgent]
ACTION: Sean to to draft comments on EARL 1.0 [4]
16:12:15 [RRSAgent]
recorded in
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