14:41:22 RRSAgent has joined #bpwg 14:41:22 logging to http://www.w3.org/2007/02/26-bpwg-irc 14:41:31 Meeting: mobileOK checker library teleconf 14:41:39 Chair: Sean 14:41:57 Agenda: http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Feb/0043.html 14:42:05 Zakim, make log public 14:42:05 I don't understand 'make log public', dom 14:42:10 RRSAgent, make log public 14:49:05 trackbot, bye 14:49:05 trackbot has left #bpwg 14:50:09 jo has joined #bpwg 14:56:58 dom, you asked to be pinged at this time 15:01:13 Zakim, code? 15:01:13 the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), dom 15:01:20 shadi has joined #bpwg 15:01:26 zakim, code? 15:01:27 the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), shadi 15:01:28 Team_(bpwg)15:00Z has now started 15:01:35 +dom 15:02:47 +Shadi 15:03:30 srowen has joined #bpwg 15:05:40 +Sean_Owen 15:06:24 nacho_marin has joined #bpwg 15:06:40 + +0208995aaaa 15:06:48 zakim, aaa is jo 15:06:48 sorry, jo, I do not recognize a party named 'aaa' 15:06:56 Regrets: Roland 15:06:58 zakim, aaaa is jp 15:06:58 +jp; got it 15:07:05 Zakim, jp is really jo 15:07:05 +jo; got it 15:07:05 zakim, jp is jo 15:07:06 sorry, jo, I do not recognize a party named 'jp' 15:07:16 nacho_marin, are you joining the call? 15:07:21 yes 15:07:59 +Rodrigo 15:08:07 zakim, Rodrigo is me 15:08:07 +nacho_marin; got it 15:08:29 Zakim, Rodrigo is nacho_marin 15:08:29 sorry, dom, I do not recognize a party named 'Rodrigo' 15:08:57 Sean: mobileOK is nearing the end of Last Call 15:09:11 ... as this is tests-based, it would be nice to have a ref implementation 15:09:26 ... already have several tentative implementations: w3.org, TAW, Mr Dev from dotMobi 15:09:48 ... would like to develop a 4th implementation that would serve as a reference implementation that these existing projects could use 15:09:57 ... that's what this task force is about 15:10:46 ... we need to look at the next steps so that we can keep up with the schedule of the mobileOK basic spec 15:10:57 ... probably moving forward in March/April timeframe 15:11:08 ... I have seen 3 main issues coming up in our discussions: 15:11:32 ... 1. Implementation should produce an intermediary DOM / XML document with a bunch of information on the document retrieved 15:11:41 ... the idea being to allow to process it through XSLT 15:11:55 ... also, the test output should be made available as a detailed DOM / XML document 15:12:07 ... discussions whether it's worth having an intermediate XML document at all or not 15:12:09 q? 15:12:28 q+ to respond to sean 15:12:43 Shadi: besides EARL, the ERT WG is working on an RDF vocabulary to describe HTTP 15:12:50 ... in terms of protocol, based on the RFC 15:13:01 ... this allows to describe fully a web resource, including headers etc 15:13:16 ... useful to be able to describe exactly what web resource we got from the server 15:13:33 ... also useful for ajax-based applications 15:13:50 Sean: I see; allows to describe response/request, headers and body 15:13:58 ... Makes a lot of sense to re-use that 15:13:59 q? 15:14:14 http://www.w3.org/TR/HTTP-in-RDF/ 15:14:18 Shadi: we hope to go to LC with EARL and that WG note by the end of this month 15:14:32 ack jo 15:14:32 jo, you wanted to respond to sean 15:15:21 Jo: probably fits, but we need to capture arbitrary http headers, not only the ones that are defined in HTTP 15:15:37 Shadi: we support additional headers as extensions point in our vocabulary 15:16:14 Jo: We would also probably want to represent both the headers as put by the client/server as well as some canonicalized version of them 15:16:46 ... I'm not personally set about using RDF or not, as long as the requirements are met 15:17:06 ... I think we need to focus on requirements at this point, rather on which specific format 15:17:34 Sean: there is some debate between procedural (e.g. in Java) vs declarative (e.g. XSLT) ways 15:18:00 q+ 15:18:18 Jo: question about whether a procedural implementation is acceptable for a reference implementation 15:18:45 ack me 15:19:58 Dom: I don't think it's a problem to focus on a procedural impelementation 15:20:05 ... most of the work needed is procedural anyway 15:20:26 Sean: tend to agree with that 15:20:45 ... I don't think we should take language-independence as a requirement, unless it's easily achievable 15:21:21 Jo: I think both approach can be defended 15:21:50 q+ 15:21:53 ack me 15:23:12 q+ 15:23:25 q- 15:23:34 dom: agree that we need some requirements, but we also need to start coding 15:23:45 ... needs some requirements e.g. for interfacing with applications that would rely on our library 15:23:59 Sean: in terms of our requirements, we're clearly basing our stuff on mobileOK basic 15:24:23 ... we need more work on some unspecified aspects (e.g. error handling, etc) 15:24:48 ... we also need to produce some useful output, including pass/warn/fail, but also additional informations 15:24:51 q+ 15:24:52 ack me 15:25:27 jo: for dotMobi, one of our big requirements is to be able to add more tests, i.e. extensibility 15:25:46 ... an intermediary format would certainly help adding ad-hoc processing 15:25:58 ... I'm happy to take the lead on writing up requirements 15:26:07 sean: agree with extensibility 15:26:18 ... for me that implies that the output should be very rich 15:26:24 ... (input headers, body, etc) 15:27:00 ... but that's a separate concern from portability which I think was the main trigger behind XSLT 15:27:04 Jo: not quite 15:27:33 ... we need as much information as possible somewhere available for extensions 15:27:58 q+ to explain requirements based on his experience with the checker 15:28:13 q+ to take up Jo's offer on leading requirements 15:28:20 q+ to ask about sharing code 15:28:43 ack me 15:28:43 dom, you wanted to explain requirements based on his experience with the checker and to take up Jo's offer on leading requirements and to ask about sharing code 15:30:13 q+ to describe EARL pointers and invite review 15:31:57 dom: brain dump of what we need: what things triggered a failure (pointers, code quote), cascading errors, 15:32:05 q+ to elaborate on cascading errors 15:32:08 ... I think we should offer Jo's offer to edit requirements 15:32:25 ... would also be nice to look at the existing code bases to identify more requirements 15:32:30 sean: agree 15:32:41 ... I'm still not sure we need the intermediary requirements 15:32:55 q+ to say that the intermediary document should be trivial to produce 15:33:06 ack me 15:33:07 dom, you wanted to say that the intermediary document should be trivial to produce 15:34:04 dom: I think producing the intermediate document should be trivial if we do our work right 15:34:09 ... don't think we should focus on it 15:34:23 ... I think it should be doable as a thin layer above our library 15:34:41 ... but I don't think we need to put specific efforts on it 15:35:03 jo: I think we ought to put some specification effort in the manner of processing that allows to come to the conclusions that you want to take 15:35:24 ... I think the pre-processing effort needs to be specified, whether it is done in java or in a declarative way 15:35:42 q+ 15:35:47 ack jo 15:35:47 jo, you wanted to elaborate on cascading errors 15:36:54 ... there are some assumptions that may need to be made when hitting non well-formed content 15:37:02 ... e.g. how to handle a document that is not encoded in utf8 15:37:14 ... is this something that the ref implementation should handle? 15:37:29 ... more generally, how much the reference implementation should leave to value-added implementations? 15:37:39 ... I think this needs to be described in requirements 15:37:47 q? 15:37:52 ack me 15:37:53 shadi, you wanted to describe EARL pointers and invite review 15:38:18 shadi: going back to the discussion on cascading errors and on sources of errors 15:38:47 ... as part of EARL, we have developed "pointer methods in RDF" which describes several ways to say what part of the tested content triggered an error 15:39:04 ... EARL doesn't make any assumption how the tests fit in a test suite 15:39:14 ... it assumes some atomicity of the tests cases 15:40:36 Sean: so EARL doesn't define tests dependency? 15:41:10 Shadi: right 15:41:32 Sean: probably not a big problem; that maybe something left to additional implementations 15:42:05 ... I agree with Jo that the hard part will be to figure out e.g. whether a document is properly encoded or not, and this will need to be done through procedural encoding 15:42:10 s/encoding/coding/ 15:42:42 q? 15:42:50 ... whether this is translated into a boolean flag or into some XML markup, the added value from XSLT doesn't seem obvious 15:42:53 ack sr 15:43:03 jo: "I don't disagree" 15:43:14 ... I think it's desirable to make things as atomic as possible 15:44:32 q+ 15:44:54 q- 15:44:55 ... I guess the question is really whether how much XPath can offer 15:45:10 Sean: I don't have a strong objection to define a modular architecture 15:45:34 ... if we say we need to define an intermediary document, I think this will roughly double the amount of work we'll need to do 15:45:45 q+ 15:45:54 ack me 15:47:07 q+ 15:47:13 q- 15:47:36 dom: intermediate document could be useful as an API for code built on top of our libraries 15:47:55 ... still think we need to focus on the hard work (work with ill-formed, ill-encoded content, etc) 15:48:02 sean: ok, let's give it a try 15:49:08 PROPOSED RESOLUTION: test implementation will produce an intermediate representation specifying the results of accessing and evaluating ("preprocessing") a resource. This representation will be available as a DOM / XML document 15:49:30 PROPOSED RESOLUTION: as many tests as is reasonable will be implemented in terms of the intermediate DOM 15:49:53 PROPOSED RESOLUTION: test results will be available not only in Java API form but in a comparable DOM form expressed using EARL 15:50:09 [sounds good to me] 15:51:02 PROPOSED RESOLUTION: reference implementation will be written in Java 15:51:03 no objections here 15:51:20 RESOLUTION: test implementation will produce an intermediate representation specifying the results of accessing and evaluating ("preprocessing") a resource. This representation will be available as a DOM / XML document 15:51:24 RESOLUTION: as many tests as is reasonable will be implemented in terms of the intermediate DOM 15:51:33 RESOLUTION: test results will be available not only in Java API form but in a comparable DOM form expressed using EARL 15:51:34 RESOLUTION: test results will be available not only in Java API form but in a comparable DOM form expressed using EARL 15:51:46 RESOLUTION: reference implementation will be written in Java 15:52:03 Topic: milestones, ownership 15:52:35 ACTION: Jo to summarize the requirements in a note 15:53:16 agenda+ setting up regular meetings or keeping it on an ad-hoc basis? 15:54:02 q+ 15:54:10 q- 15:54:32 Jo: I think it's useful to spend some time on refining the requirements 15:54:52 Sean: I tend to agree, but I certainly want to move forward with coding 15:55:19 +1 to have Sean driving this 15:55:47 Sean: I'm willing to drive this, but don't want to take too much control 15:55:58 ... I'm open to other persons doing this 15:56:12 Jo: agree with Dom about you driving this 15:56:27 ... still think it's useful to have a requirements document in // with our code effort 15:56:44 [I agree that it would most useful if we could document what our code does in // to developing the code] 15:56:53 Sean: sounds good 15:57:30 PROPOSED ACTION: Sean to sketch some code matching what we discussed today 15:57:49 Jo: FWIW, what I have in mind is mostly a picture of what we want to do 15:58:10 Sean: I think I can write up what I want us to do in terms of code, illustrated with code 15:58:23 ACTION: Sean to incorporate the resolutions in sketch code 15:58:31 ACTION: Sean to explain clearly the overall architecture 15:58:51 Sean: maybe premature to talk about deadlines 15:58:56 ack me 15:59:58 dom: plan AFAIK is to have mobileOK basic CR end of April 16:01:18 dom: I think we should plan to have some version of our code ready around that time as much as possible 16:01:36 Sean: Ok, so our goal should have to something even in beta form available on the Web around that timeframe 16:02:13 Jo: if this is going to be promoted by the BPWG as a ref implementation, whether this goes through Rec track or not, it needs the same level of scrutinity as a rec track doc 16:02:55 q+ 16:02:55 q+ to share similar experiences with public perception in WAI 16:03:21 ... we also needs to consider questions regarding maintenance of the code as ref impl 16:03:25 ack me 16:04:07 q+ 16:04:07 ack me 16:04:09 shadi, you wanted to share similar experiences with public perception in WAI 16:04:23 dom: don't think we should target to be labeled as ref impl anytime soon 16:04:33 ... although we should develop it as if it was one 16:04:49 ... I think we can probably get the WG to talk about our implementation as part of the CR phase 16:05:02 shadi: yes, we have had difficulties in that regard in the past 16:05:06 ... in WAI 16:05:19 q- 16:05:21 ... there is a difference between W3C building a tool and somebody else doing it 16:05:41 srowen: there is a difference between W3C implying that something is mobileOK with somebody else 16:05:47 ... not sure about process/terminology 16:05:58 ... don't really care about it being called "ref impl" at this time 16:06:06 ... but would like it to be available on w3.org 16:06:22 ... I think it should be a de facto ref impl 16:06:27 ack me 16:08:04 dom: I think if we manage to produce something better than the current checker, I don't see any reason not to replace it with the new code 16:08:09 jo: agreed 16:08:13 sean: ok, that's great 16:08:26 jo: would just need some caviar around it 16:08:40 ... (incomplete, not fully tested, work in progress, etc) 16:08:43 ack me 16:09:31 PROPOSED RESOLUTION: if implementation is as useful / robust or more so than existing checker, as decided by this task force, then we will try to use it to power validator.w3.org along with the release of mobileOK Basic Tests 1.0 in late April 16:10:05 erm, let me add some text to that: 16:10:27 PROPOSED RESOLUTION: if implementation is as useful / robust or more so than existing checker, as decided by this task force, then we will try to use it to power validator.w3.org along with the release of mobileOK Basic Tests 1.0 in late April. It would be heavily caveated -- that it's beta, in progress, incomplete and must only be cited as a work in progress 16:10:32 jo: based on previous debates elsewhere, I think we need to make it clear that things that are not tested are approved in any way 16:10:35 q+ 16:10:54 ... e.g. we have had issues with Mr Dev not looking at table layouts 16:11:11 nacho: can se start with the procedural approach for sake of efficiency 16:11:19 ... and look at the intermediate document later? 16:11:29 ... so that we can make it on time for the end of April deadline 16:11:37 q+ 16:11:41 ack me 16:11:42 [I think that would be a good way forward, indeed] 16:11:44 ack sro 16:11:53 q+ 16:11:58 sean: I agree we should focus on getting as much out as we can 16:12:07 ... without taking decisions that would be hard to undo later 16:13:06 ack jo 16:13:21 jo: I don't wholy agree with this 16:13:41 ... we need to answer some specific questions 16:14:05 ... (e.G. validity of the various content formats) 16:14:18 ... that are harder 16:14:30 ... most of the other things are going to be trivial 16:14:42 ... I think doing the hard stuff is equivalent to produce the intermediate document 16:14:45 -nacho_marin 16:15:07 oooops 16:15:09 brb 16:15:29 sean: ok; sounds also like we have a deadline that we should keep in mind 16:16:22 it does not let us reach the conference 16:16:45 does this have to see with Jo disagreeing our idea? :-) 16:16:46 oops, indeed, we have gone past our scheduled time 16:16:53 sorry about that! 16:17:00 ack me 16:17:08 ok 16:18:06 Topic: next call 16:19:44 jo: let's try after the BPWG call on Thursday 16:19:58 dom: will see if we can get room on the bridge at that time 16:20:14 sean: let's delay our resolutions to that time when nacho can join 16:20:21 dom: will send the minutes 16:20:24 i can't next thursday 16:20:30 doh 16:20:31 travelling back from Zaragoza 16:20:50 what about next monday, nacho_marin ? 16:20:57 ok 16:21:22 bye! 16:21:23 -Sean_Owen 16:21:24 -dom 16:21:24 -jo 16:21:26 bye 16:21:27 -Shadi 16:21:28 next monday it is, then 16:21:29 Team_(bpwg)15:00Z has ended 16:21:30 Attendees were dom, Shadi, Sean_Owen, +0208995aaaa, jo, nacho_marin 16:22:15 RRSAgent, draft minutes 16:22:15 I have made the request to generate http://www.w3.org/2007/02/26-bpwg-minutes.html dom 16:25:46 trackbot has joined #bpwg 16:25:46 Tracking ISSUEs and ACTIONs from http://www.w3.org/2005/MWI/BPWG/Group/track/ 16:41:30 Zakim, bye 16:41:30 Zakim has left #bpwg 16:41:33 RRSAgent, bye 16:41:33 I see 3 open action items saved in http://www.w3.org/2007/02/26-bpwg-actions.rdf : 16:41:33 ACTION: Jo to summarize the requirements in a note [1] 16:41:33 recorded in http://www.w3.org/2007/02/26-bpwg-irc#T15-52-35 16:41:33 ACTION: Sean to incorporate the resolutions in sketch code [2] 16:41:33 recorded in http://www.w3.org/2007/02/26-bpwg-irc#T15-58-23 16:41:33 ACTION: Sean to explain clearly the overall architecture [3] 16:41:33 recorded in http://www.w3.org/2007/02/26-bpwg-irc#T15-58-31