08:18:28 RRSAgent has joined #bpwg 08:18:28 logging to http://www.w3.org/2007/06/13-bpwg-irc 08:18:48 Meeting: mobileOK ref implementation F2F, day 2 08:18:52 Chair: Sean 08:19:06 nacho has joined #bpwg 08:19:09 Present: Abel, Miguel, Ignacio, Sean, Dom, Roland, Ruadhan 08:19:16 Agenda: http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Jun/0001.html 08:19:21 zakim, agenda? 08:19:21 I see 9 items remaining on the agenda: 08:19:22 1. error reporting, error codes and I18N [from dom] 08:19:24 2. test suites, and acceptance criteria, beta period [from dom] 08:19:27 4. issues with XSLT Framework, standardization of output format [from dom] 08:19:29 5. CSS Library [from dom] 08:19:30 6. Exceptions hierarchy [from dom] 08:19:32 7. Cacheing behavior [from dom] 08:19:33 8. Documentation: schemas, introduction, ... [from from Jo via dom] 08:19:34 9. setting up configuration framework (e.g. for language setting, authentication, ...) [from dom] 08:19:37 10. audit/estimate to completion [from dom] 08:19:54 -> http://www.w3.org/2007/06/12-bpwg-minutes.html Minutes of Day 1 (June 12) 08:22:00 roland has joined #bpwg 08:24:07 dom has joined #bpwg 08:34:23 dom has joined #bpwg 08:44:37 dom has joined #bpwg 08:46:44 jo has joined #bpwg 08:51:24 RRSAgent, make log public 08:51:30 RRSAgent, draft minutes 08:51:30 I have made the request to generate http://www.w3.org/2007/06/13-bpwg-minutes.html dom 08:54:52 dom has joined #bpwg 08:57:21 miguel has joined #bpwg 08:57:38 abel has joined #bpwg 09:05:07 dom has joined #bpwg 09:10:56 -> http://lists.w3.org/Archives/Public/public-mobileok-checker/2007May/att-0087/thirdparties_study.html Third Party study from CTIC guys 09:12:51 (the latest version of that document on Google Docs is dated June 12) 09:14:12 ScribeNick: dom 09:14:23 Topic: Using errors reported from other tools 09:14:46 Sean: I think we need to take an ad-hoc approach, do our best with what the tools provide, and if they don't, find our ways around 09:15:22 dom has joined #bpwg 09:15:37 Abel: one of the problems we identified is that most of these tools don't provide error codes 09:15:57 ... for instance, the XHTML module in JHove only outputs a message and a location 09:16:09 ... the image module provides a message and a bytes offset 09:16:45 Sean: I think it's fine for us to parse the error messages; it's ugly, but probably shortest way forward 09:16:55 ... would be better if they provided a better API 09:18:02 Miguel: the difficulty will be to identify all the possible messages 09:18:32 ... in Jhove, they are hardcoded in the source itself, not even in property files 09:19:43 ... and of course, the messages are parametrized (e.g. to include the name of the element that triggered the validity error) 09:19:59 Jo: if we have to review all the errors triggering code, we may as well fix it! 09:21:36 Sean: one way to get around that is simply to include the messages that Jhove sends to us in the error messages we send back to the user 09:21:44 Dom: but that's a killer in terms of I18N 09:21:51 Sean: right, that's the big downside 09:21:56 ruadhan has joined #bpwg 09:22:10 ... but I would still favor just doing it 09:22:38 jo: I guess the question is whether perfect error reporting is part of our requirements or not 09:23:16 ... we need to strike a balance between what we would like to achieve, what we need to achieve and what we can achieve in a reasonable amount of time 09:25:02 Sean: I think we should focus on what we have to do first 09:25:37 dom has joined #bpwg 09:26:02 Jo: whatever we decide, we just need to make clear whatever the restrictions our first version will have 09:26:59 ... too bad libraries don't handle this well 09:27:31 Dom: I note *our* library will have exactly this same problem given the decision we took yesterday (non-parametrized error messages) 09:28:37 Sean: I think we should proceed with the simple solution for now, and fix it later 09:28:41 RRSAgent, draft minutes 09:28:41 I have made the request to generate http://www.w3.org/2007/06/13-bpwg-minutes.html dom 09:31:45 [discussions on whether we should favor a pragmatic vs esthetical approach] 09:33:03 MikeSmith has joined #bpwg 09:34:22 Dom: what you guys are doing in your tools? 09:34:41 ... The checker just sends back the messages the XML validation library produces 09:34:45 Ruadhan: same for us 09:35:09 Miguel: in TAW, we had to hack around the XML validation to get translated messages 09:35:21 ... The CSS library allowed for localization, so we didn't have the same problem 09:35:52 dom has joined #bpwg 09:36:05 Sean: let's have a better system as our goal for version 1.0, but move forward with the simple version now 09:36:27 Miguel: if so, we should probably separate the data in the results 09:36:49 ... so that it's clear that some part of the messages aren't produced by our library 09:37:44 Sean: sounds good, indeed 09:38:28 ... so we amend the results document as we discussed yesterday to create an additional element (e.g. "details") to include third party library messages 09:38:55 q+ to propose that we have somewhere a reference results document so that we can now at any time the expected structure of the results doc 09:40:29 ack dom 09:40:29 dom, you wanted to propose that we have somewhere a reference results document so that we can now at any time the expected structure of the results doc 09:40:55 Sean: point taken; I guess the reference would be what is in the test suite 09:43:40 Jo: random thought of the day: should the individual test reported by the XSLTs have a specific version number attached? 09:43:45 dom: don't think that's necessary 09:44:01 ... let's wait until we would actually need it 09:44:43 Jo: also, we need to look at how to report errors from the library 09:44:53 ... e.g. out of memory errors 09:45:14 Sean: don't think that needs to be part of the results document 09:45:22 ... just throw an exception 09:45:36 Jo: I think the results document should give some indication of this 09:45:43 ... e.g. with a CannotTell 09:46:08 dom has joined #bpwg 09:47:49 Dom: I think both approach are reasonable 09:48:03 ... the only question is whether exceptions get handled in or out of the library 09:50:30 ... I think the difference is whether you consider the API to be the Java API or the XML API 09:50:39 ... don't think we've ever made a clear decision on this 09:51:21 Jo:: we should probably move on for now, but we'll need to get back to this 09:52:11 Ruadhan: if the results document is a report, it should always report whether a test passed or failed, it can't be silent on it 09:56:23 dom has joined #bpwg 09:57:32 dom: if we can solve this with just another wrapper to catch exceptions, it's probably worth keeping the exceptions, as this gives us the best of the two worlds 09:57:35 sean: doesn't seem very clean 10:03:39 dom: I say, let's keep the Java API clean, and how exceptions are handled can be decided later on, or even by a wrapper library should the need arise 10:03:55 sean: still not convinced, but we should move on 10:06:38 dom has joined #bpwg 10:16:53 dom has joined #bpwg 10:27:08 dom has joined #bpwg 10:32:52 zakim, close agendum 1 10:32:52 agendum 1, error reporting, error codes and I18N, closed 10:32:53 I see 8 items remaining on the agenda; the next one is 10:32:54 2. test suites, and acceptance criteria, beta period [from dom] 10:32:58 Zakim, next agendum 10:32:58 agendum 2. "test suites, and acceptance criteria, beta period" taken up [from dom] 10:33:28 Sean: we already have a set of unit tests, which hopefully we can use to convince the BPWG that we do indeed implement mobileOK Basic 10:34:01 Jo: one of the questions is what part of the results document constitute a proof that your checker is indeed a mobileOK checker 10:34:15 Sean: clearly the error messages shouldn't required 10:34:35 ... I guess it should be that you do report the right errors 10:36:34 [discussions on protecting mobileOK checker through test suite] 10:36:42 Jo: still, we need to make sure our test suite is complete 10:36:58 Sean: I say we add tests as needed 10:37:23 dom has joined #bpwg 10:38:02 Jo: we want to keep in mind that the test suite will need to be versioned 10:38:08 zakim, close this agendum 10:38:08 agendum 2 closed 10:38:09 I see 7 items remaining on the agenda; the next one is 10:38:10 4. issues with XSLT Framework, standardization of output format [from dom] 10:38:29 Zakim, close agendum 4 10:38:29 agendum 4, issues with XSLT Framework, standardization of output format, closed 10:38:31 I see 6 items remaining on the agenda; the next one is 10:38:32 5. CSS Library [from dom] 10:38:40 zakim, take up agendum 6 10:38:40 agendum 6. "Exceptions hierarchy" taken up [from dom] 10:38:52 Abel: currently we only have one type of Exception 10:39:04 ... we could have two kinds of Exceptions 10:39:57 ... to distinguish Fatal Errors (e.g. config file not found) vs exceptions raised in the test execution (e.g. exception raised by Jhove) 10:40:15 ... (this relates to our earlier discussion on error reporting) 10:41:25 Sean: so the question is whether we want to subclass TestException 10:41:52 ... my take is someone using our code wouldn't care about what type of the exception 10:42:08 ... I guess we could chain exceptions if we do want a hierarchy 10:42:24 ... I don't oppose having a hierarchy if there is a use case for that 10:42:57 Abel: if one test failed because of of a failure of a third party, what is the result? 10:43:07 Sean: that's indeed the question we just discussed 10:43:12 ... do we report it or not? 10:44:30 ... I guess Dom and Jo argued for outputting a minimal results document with a CannotTell message 10:44:52 dom: I think we were actually asking for a document as complete as possible (i.e. including the results that were indeed processed) 10:45:07 ... and also some information as to why one or more of the tests couldn't be run 10:45:18 Nacho: not sure we need a cannot tell, since it's not defined in mobileOK 10:45:25 ... a warning should probably be enough 10:46:07 Sean: I still think we should get back to that later 10:47:38 dom has joined #bpwg 10:48:43 ... if we keep exceptions, I think the current flat exception space is ok, although I'm open to expand it if use cases suggest it 10:49:04 ... if we report cannottell outcomes, I don't think we should raise exceptions at all 10:49:09 Zakim, close this agendum 10:49:09 agendum 6 closed 10:49:10 I see 5 items remaining on the agenda; the next one is 10:49:11 5. CSS Library [from dom] 10:49:12 zakim, next agendum 10:49:12 agendum 5. "CSS Library" taken up [from dom] 10:49:27 Nacho: I think we should decide what library to use 10:49:44 Sean: so, in our choices, one was good at syntax parsing, and the other @@@ 10:50:10 Miguel: another point to consider is how to turn the CSS style sheet into XML if we want to process it through XSLT 10:50:35 Jo: I'm not quite sure what we should do here 10:50:59 ... I'm tempted to only integrate the error reports from the library in the moki document instead 10:51:21 ... the library that turns CSS into XML has too many flaws for our own use 10:51:47 ... and it would probably be out of our scope to develop such a library at this point 10:51:59 ... (although it would certainly be nice to be able to do so) 10:53:35 ... The best option is probably to with the SAX CSS parser, since it's the most likely to work for our purposes 10:54:05 Sean: so we need to both validate and analyse the style sheets 10:54:19 ... is one library enough or do we need two for that? 10:54:50 Miguel: the SAX parser can only be used for analysis of the style sheet 10:55:08 ... the only library I know to validate a style sheet against CSS 1 is the W3C CSS Validator 10:56:03 Dom: another option is to use the SOAP interface for the CSS Validator 10:56:21 ... (although it prevents to use our system as an all-in-one package) 10:56:37 Sean: I'd rather keep it in all-in-one 10:57:12 ... so can we use the css validator code for our purposes? 10:57:26 Miguel: yes; the only problem is that it is a bit slow 10:57:41 Nacho: I think it's probably good enough for our first version of the checker 10:57:53 dom has joined #bpwg 10:58:19 Jo: this raises the point that we should have a wrapper for our validation code 10:58:35 ... so that it's easier to swap validators if we choose to 10:59:12 ... identifying a common interface around these validators would be a good way to identify what we want out of these validators anyway 10:59:19 ... our current code is ugly 10:59:32 Sean: I'm personally fine with binding directly to the library 10:59:41 ... it also obscures less the code 10:59:51 ... and it allows a greater use of the underlying API 11:00:01 Jo: true... probably a matter of taste 11:00:40 Sean: also, we're already using well-defined API (SAX, XML validation, etc) 11:01:00 ... and if we were to change a validator, I'm not sure an abstract API would actually save us so much time 11:01:13 Jo: I don't disagree with you 11:02:29 ... it would certainly be helpful to have a common interface for validators, that said 11:02:47 dom: note that the W3C Unicorn project has more or less defined such an API, if you're interested 11:03:15 Jo: sounds interesting; anyway, it sounds like we're not going to proceed that way for the time being 11:03:27 Sean: here is what I think we should do: 11:03:41 ... we should remove the JXCSS thingy I had started 11:03:54 ... we use the W3C CSS validator for validation 11:04:05 ... and SAC for the actual test implementation 11:04:34 Jo: one of the difficulties is to deal with inline CSS 11:04:42 Sean: do we allow the style attribute? 11:05:03 Dom: we do 11:05:13 Sean: so that will need to be implemented 11:05:37 ... fortunately, our tests on CSS are fairly simple (e.g. don't use "px") 11:07:03 ACTION: Ignacio to work with Miguel and Abel to implement the CSS stuff (removing JXCSS, implement validation, and use SAC for test implementation) 11:07:03 Created ACTION-515 - Work with Miguel and Abel to implement the CSS stuff (removing JXCSS, implement validation, and use SAC for test implementation) [on Ignacio Marn - due 2007-06-20]. 11:08:08 dom has joined #bpwg 11:08:51 Jo: I still think we should keep as a goal to have at some point an CSS-in-XML implementation in moki 11:09:11 Dom: how hard would it be to use SAC to generate such a thing? should be relatively straightforward, isn't it? 11:10:08 ACTION: Jo to evaluate how hard it would be to produce XML out of CSS stylesheets using SAC 11:10:08 Created ACTION-516 - Evaluate how hard it would be to produce XML out of CSS stylesheets using SAC [on Jo Rabin - due 2007-06-20]. 11:10:21 zakim, close this agendum 11:10:21 agendum 5 closed 11:10:22 I see 4 items remaining on the agenda; the next one is 11:10:23 7. Cacheing behavior [from dom] 11:10:59 Zakim, next agendum 11:10:59 agendum 7. "Cacheing behavior" taken up [from dom] 11:11:15 Dom: the question is what caching should our library do? 11:11:40 Jo: indeed, what do we cache and under what circumstances? esp. given what we discovered yesterday re caching and URIs 11:14:10 dom: two caching questions: keeping a list of URIs already downloaded in the given request vs keeping a resource that was downloaded for a previous analysis so that you don't have to do it again 11:14:23 Jo: I think we shouldn't do the latter, and should do the former 11:16:37 ... we also need to discuss what to do with regard to URIs given our discovery of yesterday 11:17:12 Dom: [different cases of what browsers do in terms of canonicalization] 11:17:37 Sean: think we should keep it simple (i.e. simple string comparison), and that should be pretty close to what current browsers do 11:17:48 ... unlikely to happen very often anyway 11:18:05 Dom: only thing we have to do for sure is making URIs absolute 11:18:23 dom has joined #bpwg 11:18:40 Ruadhan: I'm willing to take an action item to implement this 11:20:20 ACTION: Ruadhan to look at implementing the in-memory caching per URIs 11:20:20 Sorry, couldn't find user - Ruadhan 11:20:37 ACTION: Jo to annoy Ruadhan until he implements the in-memory caching per URIs 11:20:37 Created ACTION-517 - Annoy Ruadhan until he implements the in-memory caching per URIs [on Jo Rabin - due 2007-06-20]. 11:22:07 zakim, close this agendum 11:22:07 agendum 7 closed 11:22:08 I see 3 items remaining on the agenda; the next one is 11:22:10 8. Documentation: schemas, introduction, ... [from from Jo via dom] 11:23:16 miguel has left #bpwg 11:28:38 dom has joined #bpwg 11:38:53 dom has joined #bpwg 11:49:08 dom has joined #bpwg 11:59:23 dom has joined #bpwg 12:09:38 dom has joined #bpwg 12:19:53 dom has joined #bpwg 12:21:28 miguel has joined #bpwg 12:30:08 dom has joined #bpwg 12:40:23 dom has joined #bpwg 12:44:56 "If a Mobile Web site adapts in the forest and no user agents are there, is it OK?" -- DanA 12:49:35 Zakim, next agendum 12:49:35 agendum 8. "Documentation: schemas, introduction, ..." taken up [from from Jo] 12:49:59 ScribeNick: ruadhan 12:50:38 dom has joined #bpwg 12:50:48 sean concerns what we are going to provide in end product 12:50:52 jo: and schemas 12:51:57 Sean: introduction, overview 12:52:32 Jo: talked about yesterday 12:52:59 ... don't consider ouseleves finished until we have proivided certain amount of documentation we need to decide what this is 12:53:04 Sean: 12:53:13 ... bug tracking? 12:53:33 Dom: lets use w3c bugzilla 12:53:55 ... don't like bugzilla necessarily, we could use tacker 12:54:11 Roland: need docs in xslt? 12:54:34 Sean: we should have comments in source also 12:54:56 Sean: what else do we need? 12:55:23 Jo: nacho mentioned developer guide 12:56:21 Sean: we should take resolution not to finish until documentation is finished 12:56:54 Jo: Problem with frameworks can be lack of documentation 12:57:06 Sean: thats what developer guide will be about 12:57:12 ... schema can be done later 12:57:18 Jo: worth doing now 12:58:01 Sean: will take user guide, de. guide, 12:58:12 ... we all need to do javadoc and comments 12:58:24 ... Jo will take schema and homepage 12:58:44 nacho: i will take dev guide and user guide 12:59:16 Jo: started homepage in adhoc way - 12:59:33 ... if anyone wants to contribute, feel free, just need write access 12:59:54 Sean: homepage is real nice 13:00:03 ... need a mobile-friendly version 13:00:15 Jo: might be ok 13:00:19 Sean: anything else? 13:00:30 zakim, close this agendum 13:00:32 agendum 8 closed 13:00:33 I see 2 items remaining on the agenda; the next one is 13:00:34 9. setting up configuration framework (e.g. for language setting, authentication, ...) [from dom] 13:00:37 zakim, next agendum 13:00:37 agendum 9. "setting up configuration framework (e.g. for language setting, authentication, ...)" taken up [from dom] 13:00:53 dom has joined #bpwg 13:01:32 miguel: what about authentication parameters, locale... 13:02:00 Sean: authentication mentioned somewhere, how do we support? 13:02:12 Jo: I would like to have some minor configuration options 13:02:37 ... e.g. doing our own redirection handling, but might be nice to use standard commons redirection 13:02:49 Sean: so theres a class of development only options 13:03:08 ... my concern is that mobileOK should mean one thing and be one thing 13:03:14 ... its mobileOk or not 13:03:58 Nacho: what about validating local doc that you can upload instead of just passing URL 13:04:06 Jo: some kind of desktop integration would be nice 13:04:24 sean: configure a local directory that acts as a pseudo webserver 13:05:01 ... right now we already have something like this in the code 13:05:22 ... test docs that have a document specifying test headers and starts tomcat 13:05:33 ... might be nice to be able to test localhost 13:06:37 Jo: more will come out but we just need a single approach 13:06:51 Sean: i can name many mechanisms: 13:07:10 ... config file, xml or properties, command line / env variables 13:07:32 Nacho: verbosity level 13:07:43 Sean: of log statemts of code? 13:08:09 Nacho: granularity of results document 13:08:28 Sean: the results doc should be the same all the time for consistency 13:08:42 ... but maybe we do want a quick mode: just passes and fails 13:09:11 Nacho: could be quicker if the framework is not figuring out lines and cols etc. 13:09:32 ... was thinking about results doc to save time in processing 13:09:45 Sean: how should we store this stuff 13:10:17 Roland: set paramaters in web interface - quick mode or developer mode 13:11:08 dom has joined #bpwg 13:11:16 Roland: some config params can be set by user, there are options per request and per the whole thing 13:11:32 Sean: config file appropriate for globale options 13:11:46 ... per request, maybe a java class 13:12:02 Jo: how do we make globally accessible 13:12:30 Sean: within the code we could use some kind of singleton, get an instance of the congiuration object 13:12:53 ... or configuration could live in an object within the tester 13:13:01 Jo: but how to access it 13:13:11 Sean: yeah, without passing it all over the place 13:13:27 ... its doable... 13:13:48 Jo: i don't care how its done, is this something someone can take on? 13:14:01 ... and what is our approach to logging? 13:14:24 Sean: I suggest java.util.logging 13:14:32 Jo: many approaches 13:15:09 Sean: preference is for java.util.logging, they all pretty much do the same 13:15:11 RRSAgent, draft minutes 13:15:11 I have made the request to generate http://www.w3.org/2007/06/13-bpwg-minutes.html dom 13:15:39 Sean: when to log "fine" "info" "warn" 13:15:59 ... recap: we've identified enought that we need a mechanism 13:16:19 ... some of these features for development more than anything 13:16:25 ... and what about the global config 13:16:34 ... it think i can solve the global problem 13:16:56 ... last question is how do we get the global options in, config fuile, command line options? 13:17:09 ... I'm happy to do this 13:17:28 ... global config in a file, and a class encapsulating the options 13:17:40 ... lets talk about loggin some more later 13:18:08 ... can use our judgement about when to log fine, warn, info etc. 13:18:21 ... Any other requirement? 13:19:14 tendre que llamar lebo jiji 13:19:19 ooops, sorry 13:20:07 migeul: what about example when a page includes a reference to an image with size 1MB 13:20:16 ... do we download it, or do we set a limit? 13:20:35 Sean: yeah what about files that are 10MB, or 100MB 13:20:36 s/tendre que llamar lebo jiji// 13:20:45 s/oops, sorry// 13:20:46 Jo: yes this has been on my mind 13:21:05 ... the fact that we build a DOM in the first place is fundamental and at the heart of this issue 13:21:21 Sean: one solution is to 13:21:23 dom has joined #bpwg 13:21:39 ... in the retrieval is if the doc > 1MB just cut if off and call a network error 13:21:50 .. just to protect against malicious attacks 13:22:01 Roland: do we limit number of resources? 13:22:17 Nacho: we should have some hacking session, we try to break it 13:22:29 Sean: what do you guys do? 13:22:58 Dom: in checker there is a limit of number of redirects of 5 13:23:41 ... checker doesn't follow link to itself 13:24:04 ... Can only run it on its homepage 13:24:13 ruadhan: same for ready.mobi 13:24:45 Dom: i limit number of links 13:25:07 ... i don't limit the size of resources 13:25:19 Jo: need to both count the redirects and check they are not circular 13:25:52 Sean: lets call it "safety hazards" 13:26:01 ... redirects 13:26:05 ... #links 13:26:12 ... resource size (DOM, images) 13:26:18 ... links to self 13:26:31 ... stalled requests, timeouts 13:26:46 Jo: what about if someone is using you as a proxy for DOS attacks 13:28:53 migeul: if someone uses us as DoS, its not efficient enough as its not a fast process 13:29:24 Sean: lets revisit this at next F2F 13:31:05 zakim, close this agendum 13:31:05 agendum 9 closed 13:31:06 I see 1 item remaining on the agenda: 13:31:08 10. audit/estimate to completion [from dom] 13:31:10 zakim, next 13:31:10 I don't understand 'next', dom 13:31:12 zakim, next agendum 13:31:12 agendum 10. "audit/estimate to completion" taken up [from dom] 13:31:20 Sean: ok, where are we? 13:31:33 ... the goal is to get to something that looks like an alpha in early July 13:31:38 dom has joined #bpwg 13:31:55 ... what do we need to sort out in the next 4 weeks 13:32:33 Sean: lets recap the actions 13:33:28 Jo: css stuff needs to be done urgently 13:38:43 Sean: actions 505 to 508 don't seem critical 13:39:23 Jo: probably need a written document saying "yes its ok for me to contribute" 13:41:46 Sean: action-510 (multtiple results per test is critical) 13:41:53 dom has joined #bpwg 13:42:21 ... action-511 is critical (research annotatsion to DOM for line and col) 13:43:51 ... action-512 - should figure this out soon (line & col from xpath) 13:44:12 ... action-513 - critical also (character encoding thingy) 13:44:50 ... my intern & I will take this one 13:45:39 ... action-514 needs to be done soon (implement results and encode in EARL if poss) 13:46:07 Jo: action-516 needs to happen before 515 (both about css...) 13:50:01 Jo: do we need ownership of portions of code 13:50:45 [I just plugged tracker so that it will also watch mail sent to public-mobileok-checker, so that we get e.g. action items referenced from the Web interface] 13:50:51 Sean: was hoping that these things would be done as needed 13:51:12 ... e.g. if you need something in moki you would add it 13:51:59 ... on target 13:52:08 dom has joined #bpwg 13:52:36 dom: one question is which test do i take to implement? 13:52:49 http://docs.google.com/Doc?id=dgh5r6zs_5cb7gz3 13:53:28 Roland: i have my name on a number of tests, thats ok! 13:53:46 ... i'm not so good in Java 13:56:03 Sean: i'll work on non-test stuff for now 13:56:07 abel, nacho, could you add me to the list of authorized editors for that doc (dom@w3.org)? 13:56:21 ... alot of work here is writing test-cases... 13:57:08 ... we'll continue to use google doc to coordinate this 13:58:07 [I just got access through Jo, thanks!] 13:59:30 Sean: goal by 1st week of july is something that kind of runs, and produces meanigful output 13:59:50 Dom: i tried to run tester and used option to output separetly the results - is it just me? 14:00:21 Sean: I run the unit tests, and right now, at least one fails 14:00:33 Dom: command line runs, but just not doing what I expected 14:01:05 Jo: i thought it was working - it was me that put that command line stuff in, so there's a good chance its not working! 14:01:44 Sean: that concludes our list of items 14:01:59 ... is there anything else we haven't talked about? 14:02:07 [I just found what I was doing wrong with the command line, sorry for the noise] 14:02:21 Jo: might be worth doing a code review 14:02:23 dom has joined #bpwg 14:09:11 ACTION: Ignacio to create a preliminary version of mOK checker User Guide and Developer Guide documents 14:09:11 Created ACTION-519 - Create a preliminary version of mOK checker User Guide and Developer Guide documents [on Ignacio Marn - due 2007-06-20]. 14:12:39 dom has joined #bpwg 14:22:54 dom has joined #bpwg 14:28:10 RRSAgent, draft minutes 14:28:10 I have made the request to generate http://www.w3.org/2007/06/13-bpwg-minutes.html dom 14:28:31 Topic: code reviews 14:30:13 -> http://dev.w3.org/cvsweb/2007/mobileok-ref/ Code Source in CVS 14:30:46 ->http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/ the actual Java classes 14:31:25 -> http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/ the actual Java classes 14:33:09 dom has joined #bpwg 14:43:24 dom has joined #bpwg 14:45:16 [Jo, doesn't javadoc reacts to @todo rather than TODO?] 14:46:41 -> http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/AbstractXSLTTestImplementation.java?content-type=text/x-cvsweb-markup AbstractXSLTTestImplementation.java 14:47:42 -> http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/ThirdPartiesMessageUtils.java?content-type=text/x-cvsweb-markup ThirdPartiesMessageUtils.java 14:48:29 -> http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/ValidationMessage.java?content-type=text/x-cvsweb-markup ValidationMessage 14:49:24 (baed originally on http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/XHTMLValidationErrorHandler.java from ruadhan) 14:50:04 -> http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/HTTPXHTMLResource.java?content-type=text/x-cvsweb-markup HTTPXHTMLResource 14:53:39 dom has joined #bpwg 14:59:30 -> http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/HTTPResource.java?content-type=text/x-cvsweb-markup HTTPResource 15:02:03 -> http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/HTTPRedirect.java?rcontent-type=text/x-cvsweb-markup HTTPRedirect 15:03:54 dom has joined #bpwg 15:04:06 -> http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/URI.html Apache commons httpclient.URI 15:05:23 -> http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200306.mbox/%3cBAY1-DAV21K9h779ixr00007655@hotmail.com%3e comparison between apache commons URI and java.net URI 15:06:07 RRSAgent, draft minutes 15:06:07 I have made the request to generate http://www.w3.org/2007/06/13-bpwg-minutes.html dom 15:07:14 -> http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/TestResults.java?content-type=text/x-cvsweb-markup TestResults 15:09:14 -> http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/Preprocessor.java?content-type=text/x-cvsweb-markup Preprocessor 15:09:34 ScribeNick: dom 15:09:36 Jo: XSLT tests developer should pay attention to the normalization of HTTP headers 15:10:45 ... Preprocess::addHeader uses HeaderParseMethod to take care of the normalization 15:13:10 ... the categorization of parsing modes made in there is based on the RFC 15:14:09 dom has joined #bpwg 15:15:44 -> http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/xslt/ XSLT used in mobileok ref 15:16:11 -> http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/xslt/NonTextAlternativesTest.xsl?content-type=text/x-cvsweb-markup NonTextAlternativesTest.xsl, by Roland 15:17:29 -> http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/xslt/functions.xsl?content-type=text/x-cvsweb-markup XSLT Utility libraries 15:17:41 Roland: I try to only use match/apply-templates, no for-each 15:17:53 ... makes it easier to deal with getting serveral failures 15:19:11 ... for each of my test, I show the actual text of the test 15:20:37 ... I have a script (moki) that allows me to run the XSLT against the tests in the test directory 15:23:34 ... [explains some of the utility functions in functions.xsl] 15:24:24 dom has joined #bpwg 15:27:51 [discussions on how to present the code-snippet, on a text vs nodes basis, and what can actually be achieved in XSLT] 15:29:05 ok, I must get my plain, bye! 15:34:39 dom has joined #bpwg 15:38:19 matt has joined #bpwg 15:38:26 Proposed dates for September F2F: 4th and 5th in Sophia Antipolis 15:44:54 dom has joined #bpwg 15:46:23 RRSAgent, draft minutes 15:46:23 I have made the request to generate http://www.w3.org/2007/06/13-bpwg-minutes.html dom