- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 29 May 2007 16:44:59 +0200
- To: public-mobileok-checker <public-mobileok-checker@w3.org>
Hi, The minutes of our call today are available at: http://www.w3.org/2007/05/29-bpwg-minutes.html and copied as text below. Dom mobileOK Basic ref implementation task force 29 May 2007 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007May/0122.html See also: [3]IRC log [3] http://www.w3.org/2007/05/29-bpwg-irc Attendees Present Sean_Owen, abel, Miguel, jo, dom, ruadhan Regrets Roland, Nacho Chair Sean Scribe Jo Contents * [4]Topics 1. [5]CTIC Document 2. [6]DTDs 3. [7]aob * [8]Summary of Action Items _________________________________________________________ <dom> [9]Previous minutes 22 May 2007 [9] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007May/0089.html <srowen> (hmm wonder if Roland or Dom is joining? if not we may have all our attendees) <scribe> scribenick: jo <scribe> Scribe: Jo CTIC Document <dom> [10]A study about third parties tools regarding mobileOK checker, by the CTIC guys [10] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007May/att-0087/thirdparties_study.html Sean: can you talk us through it <abel> [11]http://docs.google.com/Doc?id=dhbw7zt7_0f8w6bq [11] http://docs.google.com/Doc?id=dhbw7zt7_0f8w6bq Abel: we looked at the thrid party tools in relation to moki ... tidy etc. ... it's desirable to make the moki document independent of the the particualr third party tools in use ... we looked at Tag Soup, but there is a problem - it doesn't record error output ... or tell you what repairs it has done ... there are other tools, (Sean proposed them in an email) ... does anyone have anything to add? Sean: I agree we need to have a way of reporting errors and problems - they are all different and don't expose their errors in a clean and consistent way ... not so worried about Tag Soup ... e.g. Jhove will be reporting all kinds of errors ... so what do we do with them ... I'd prefer not to modify the source code ... do we need to maintain a mapping between exceptions and strings ... ... it is a bit fragile ... but may be the only way of doing it ... similar approach to what Roland checked in with a load of error strings ... so how can we map from the errors ... do we need a framework? jo: I have done UTF-8/HTML validation with JHOVE. a bit disappointing jo: UTF-8 errors are reasonable; have a byte offset as a structured value jo: XHTML doesn't and its errors are fairly inscrutable want location info and internationalized strings we also want it to continue parsing for errors Ruadhan, XHTML error messages from ready.mobi are handy -- so we can get this info out of the standard library? ruadhan: yeah we get line and col numbers, can be misleading sometimes <srowen> example: using attributes in DTDs jo: looks like we need friendlier tools <Zakim> jo, you wanted to comment on TagSoup otherwise we're faced with modifying JHOVE and don't want to do that don't worry just now, but let's not hold up on the rest of the framework jo: on tagsoup, I think we'll have to dive into this more. Not good at preserving DTD for example sean: agree with Jo, and if Jhove is not useful and the standard library is for XHTML then let's ... just use that ... not so worried about Tag Soup - it's a bonus anyway ... on error reporting, I like the framework from Roland on error reporting ... and we should adopt that ... and how do we map between module error reporting and our error reporting ... it may be difficult to come up with a generic framework ... let's not hold it up too much jo: do you mean in the intermediate doc, I assume so sean: hmmm, a lot of the work is done early on ... so you have to pass it through that doc jo: I think that the moki doc can be the place to put all necessary info sean: moki can put "no errors" - if validation failed why and where ... you say there is already a structure for this in your porposed format jo: yes ... if you are going to grovel through libraries to find the string literals then you may as well change the code to report in a mroe sensible way sean: any more comments on error reporting and handling? ... if not let us set this aside a little bit, we need to dig into the code ... we do want to avoid modifying the source code if we can ... we will need a way of mapping error reporting into final strings ... need to use the moki document format to transmit errors between phases ... moving on ... more on Jhove and utf-8 jo? jo: not really, it worked and detected an error :-) DTDs sean: we do want to remove dependencies on external DTDs <dom> +100 to using a DTD catalog (W3C servers spend so much of their resources on serving DTDs...) sean: don't want failure because of dependency ... will take an action to download copies of DTDs ruadhan: I have code to do this with the Xerces resolver sean: sounds as though you can inject this into the current code base? ruadhan: sure jo: we should decide which DTDs we need to collect sean: let's have all the XHTML and the HTML 4 DTD <dom> the OMA XHTML MP dtds? <jo> if you can find them :-) <dom> xhtml mp 1.0 is available; I don't think the 1.1 and 1.2 are available at their published URIs, but they are available somewhere else I think sean: well we will have to have our own copy of that then aob sean: not done too much this week except do nit-picking on Jo's [lousy] Java ... preparing for an intern to arrive ... anyone else got a status update? jo: I'll carry on with doing the Java for moki ... and finalizing that format Abel: we will start to implement stuff - we have got our account working so we can prepare for the F2F sean: we should all come to F2F with loads of working code already submitted ... i am pleased with progress so far ... no more comments then we can end the call now ... and convene again next week ... I still have an action on error code line number Adjourned <dom> [regrets for next week, I'll be traveling]
Received on Tuesday, 29 May 2007 14:45:41 UTC