<trackbot> Date: 08 May 2007

<scribe> Meeting: mobileOK Checker Taskforce

<srowen> uh-oh, I am getting "passkey not valid" on the bridge

<srowen> dang it, I suppose we didn't make it clear to Dom we wanted to set this up

<srowen> and the machinery is not cooperating

<ruadhan> hi guys

<ruadhan> i'm having trouble dialling in too

<srowen> I have one alternate passcode here, let me try it

<srowen> 27942

<abel> Hi guys..we have problems with the call too

<abel> ok..we are going to try

<srowen> OK, 26631 works

<srowen> thanks

<srowen> I'll tell Dom we do want this slot officially going forward

zakim --> http://www.w3.org/2001/12/zakim-irc-bot.html

<scribe> scribe: Jo

<scribe> scribenick: Jo

sean: agenda is status on implementation, moki, F2F status, aob

Implementation Status

sean: we hit first milestone - i.e. something to run one test (the cacheing test) generates moki doc and results doc
... which is what we wanted to do by first of may
... milestone 2 is to finish most of tests by end of july
... 75% that is
... people working on it are "Sean, Ruadhan and Gijon Crowd"
... have not done anything since late April but I have an intern coming in too
... we divided up the work on tests (per list)
... any comment - Abel?

abel: some comments on JHOVE
... it has no module for XHTML Basic (??)

<abel> http://hul.harvard.edu/jhove/

abel: point 7 has no module of XHTML Basic or CSS

sean: we'll need to use Java validator and SAC but SAC may not be sufficient

ruadhan: thought that JHOVE did have XHTML

sean: JHOVE seems to have something for HTML and XML but not worried if it doesn't cover it
... what CSS parsing do we need now we have chucked out SCROLLING

abel: SAC will not tell us if properties etc. are wrong only checks well formedness
... need a CSS validator

Sean: agree - we will need to augment what SAC does - whoever needs this first should do it and post to list

jo: should not use W3C validator for XHTML

Sean: OK

jo: can you post current sample for Result format so I can work from that

Sean: yes

jo: should we do validators in a JHOVE compaitble format?

sean: dunno if necessary
... framework looks OK and better than no starting point at all for stuff that exists in JHOVE but no point in that for CSS etc.
... I'll be checking in code and proposing changes on mailing list
... a lot of stuff will have to change - so discuss on list

nacho: shouldn't we stabilise the moki format before doing other things? e.g. errors are important and need to be defined - plus their relationship with library errors
... we should try to define in a way that is as transparent as possible a way so it can work with each of the various libraries
... try to define which parts are stable and which are still to be discussed

jo: yes, I agree, but don't have time for a week and a half

sean: think it will be hard to do the document before doing the code - so it will need to be iterative
... suggest that we discuss changes on the list
... think error messages can't be presented directly from underlying library

jo: should we have a Wiki to record error messages as we come across them during development

nacho: I think we should know which bits are more stable and which more dangerous in the moki format
... e.g. the error handling needs to be very carefully considered
... it's tricky we should worry about it

jo: think that the rror handling should be an error reference plus text

nacho: we can make a proposal

sean: changes to the document will only come about as a result of requests and proposals for changes
... errors should not be library specific errors, think I do see value for a reference/wiki for errors
... think it will be hard to do it comprehesnively
... do we need to do this?

jo: think it would be useful to do this

nacho: need to make sure we catch all errors thrown by the libraries
... need to define a general strategy / mapping for library errors to moki
... we need to wrap some errors one way and some another - needs to be made library independent

sean: yes think so - is there a general strategy for this
... but think that jo wants to standardise all errors and warnings
... how we catch them is a different question

jo: yes, don't know how we can avoid this as we need to correlate checker behaviour with test cases and know that the checker is throwing the right error in the right circumstances

sean: so everything needs some kind of ID e.g. CACHING-WARNING-39
... do we need a WIKI for this

jo: think there needs to be some level of sharing, plus needs to be used for user documentation
... at this stage perhaps its OK if we just each know where each others errors etc are

sean: how about I create a property file and circulate examples
... to centralise error handling
... suggest we adopt Jo's idea and standardise and centralise e.g. CACHING-FAIL-150 and I will take an action to do this if everyone agrees ..

+1 to sean

<abel> +1

<roland> +1

<scribe> ACTION: Sean to create property file for error handling and demostrate its use [recorded in http://www.w3.org/2007/05/08-bpwg-minutes.html#action01]

F2F Location etc.

Sean: June 12 and 13 in London at Google Offices
... similar format to Dublin F2F - resolve issues leading to Milestone 2 - 75% implementation
... then we can work on the final release for mod-September
... office is near Victoria station, everything is set up, delicious lunch, comfortable chairs etc.!
... 8 people seem to be coming so far:
... Sean, Jo, Ruadhan, Nacho, Miguel, Abel, Roland
... need to confirm Dom, maybe Kai and the mobileOK Pros

MOKI Document

Sean: any thoughts on this?

jo: apologies for not doing work on this but I am stuck in mobileOK doc

sean: abel mentioned that he didn't think we should talk about validity in a declarative way

abel: do we need to talk about CSS in XML, maybe we don't need this any more now that SCROLLING is gone

sean: SAC produces output in a structured form so that may be enough

jo: if there is a trivial way of expressing CSS in XML then it would be useful to do this

sean: must be a standard way of doing this

jo: yeah, but haven't found it

<scribe> ACTION: sean will find out or invent the canonical representation of CSS in XML [recorded in http://www.w3.org/2007/05/08-bpwg-minutes.html#action02]

ac sro

AOB

<scribe> ACTION: Sean to post current example results format to list [recorded in http://www.w3.org/2007/05/08-bpwg-minutes.html#action03]

Sean: everyone to continue to work on code and raise questions on list, make sure to check code in on CSS and on list

<scribe> ACTION: Sean to check with Dom about the call next week [recorded in http://www.w3.org/2007/05/08-bpwg-minutes.html#action04]

jo: can't make it next week - can't make it alternate weeks on Tuesday pm

This is scribe.perl Revision: 1.128  of Date: 2007/02/23 21:38:13  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/SAX/SAC/
Succeeded: s/genenral/genenral/
Succeeded: s/genenral/general/
Succeeded: s/comoftable/comfortable/
Succeeded: s/ACTION/ACTION:/g
Found Scribe: Jo
Inferring ScribeNick: jo
Found ScribeNick: Jo
Default Present: Sean_Owen, abel, +0208995aaaa, jo, nacho, miguel, +049221650aabb, Roland, +01854aacc, Ruadhan
Present: Sean Nacho Miguel Abel Roland Ruadhan Roland
Found Date: 8 May 2007
Guessing minutes URL: http://www.w3.org/2007/05/08-bpwg-minutes.html
People with action items: sean