W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > May 2007

[minutes] mobileOK Checker Telecon, 2007-05-08

From: Jo Rabin <jrabin@mtld.mobi>
Date: Tue, 8 May 2007 16:04:52 +0100
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B42B3950@mtldsvr01.DotMobi.local>
To: <public-mobileok-checker@w3.org>


Pasted as text below and prettily at [1].

Cheers
Jo

[1] http://www.w3.org/2007/05/08-bpwg-minutes.html


---

MWI BPWG Teleconference
8 May 2007

See also: IRC log
Attendees

Present
    Sean, Nacho, Miguel, Abel, Roland, Ruadhan, Roland
Regrets
Chair
    Sean
Scribe
    Jo

Contents

    * Topics
         1. Implementation Status
         2. F2F Location etc.
         3. MOKI Document
         4. AOB
    * Summary of Action Items

 

 

<scribe> Meeting: mobileOK Checker Taskforce

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
Summary of Action Items
[NEW] ACTION: Sean to check with Dom about the call next week [recorded
in http://www.w3.org/2007/05/08-bpwg-minutes.html#action04]
[NEW] 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]
[NEW] ACTION: Sean to post current example results format to list
[recorded in http://www.w3.org/2007/05/08-bpwg-minutes.html#action03]
[NEW] 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]
 
[End of minutes]
Received on Tuesday, 8 May 2007 15:05:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:03 GMT