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

[minutes] Checker F2F Day 2 (Sep 5)

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 05 Sep 2007 15:43:33 +0200
To: public-mobileok-checker <public-mobileok-checker@w3.org>
Message-Id: <1188999813.30754.18.camel@cumulustier>

Hi,

The minutes of our meeting today are available at:
http://www.w3.org/2007/09/05-mobileok-minutes.html

linked from:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Checker/

and copied as text below.

Dom

                mobileOK checker Task Force F2F, day 2

5 Sep 2007

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Aug/0084.html

   See also: [3]minutes Day 1 | [4]IRC log

      [3] http://www.w3.org/2007/09/04-mobileok-minutes
      [4] http://www.w3.org/2007/09/05-mobileok-irc

Attendees

   Present
          Sean, Dom, Nacho, Roland, Ruadhan, Abel, Miguel, Jo

   Regrets
          None

   Chair
          Sean

   Scribe
          roland, nacho, ruadhan

Contents

     * [5]Topics
         1. [6]Review open actions from last F2F
         2. [7]Open Issues
     * [8]Summary of Action Items
     _________________________________________________________

   <dom> ScribeNick: roland

   sean: agenda for today

Ruadhan, Jo status and test review

   Ruadhan: update xslt implementation google doc
   ... do we have a review process for the tests?
   ... actually no line numbers are reported
   ... and come back to CSS discussion

   srowen: if a test exist for a test, it is done

   dom: if you have done your test, somebody else have to test if this
   is done

   srowen: line number
   ... xerces and saxon discussion
   ... we can use best of both parsers, line numbers from saxon and
   xerces for the other stuff

   Ruadhan: (shows a result example) how to display the line numbers in
   the doc?

   srowen: this method is used in the CSS method
   ... walking through the tests and check where the position is needed

   actually we don't see a example, but it's work

   <srowen> TODO need to come up with working example for adding line
   number in XSL-based tests

   Ruadhan: if external elements like background images are used in the
   CSS
   ... but are not referenced in the document
   ... we do not have this add to the page test

   <dom> ... they'll get counted as part of the external resources

   jo: also a problem if as example: .body is overwritten by body.body

   srowen: we should mark this as a known issure

   <srowen> TODO track the CSS cascade issue as a known issue

   <dom> [9]Lobo: Java Web Browser "Lobo (previously known as Warrior)
   is an open source web browser that is written completely in Java. It
   is undergoing active development with the aim to fully support HTML
   4, Javascript and CSS2."

      [9] http://html.xamjwg.org/java-browser.jsp

   jo: discussing about CSS cascade and mobileOK doc
   ... CSS cascade handling is hard stuff

   srowen: we should note this as an issue

   ruadhan: (shows an example) background images that are defined but
   the class is not used are not loaded
   ... by Firefox

   srowen: another agenda item: Test for tests
   ... all tests are located in a separate directory
   ... you do not have to write source code for tests
   ... for each test are directories where the testcases are located
   ... the primary test document is 'index.xhtml'
   ... if you want additional headers, use 'index.xhtml.headers'
   ... runs on localhost:8888
   ... if you use other files in the doc, place them in this directory
   ... the only tools that you need is java and ant
   ... if you want to build it, simply run 'ant'
   ... if you want to run the test, run 'ant test'
   ... when the test fails, the expected result isn't correctly

   <srowen> TODO add ability to run one test at a time

   <srowen> one test test that is

   <dom> [generated URIs look like
   [10]http://localhost:8080/StyleSheetsUseTest/2/index.xhtml FWIW]

     [10] http://localhost:8080/StyleSheetsUseTest/2/index.xhtml

   srowen: thats it!

   dom: we need cross tests

   <dom> TODO: check that each warn/fail condition is minimally tested
   by our test suite

   srowen: test java code is located in a separate directory

   <srowen> TODO build a way save test run results as the golden test
   result

   jo: could you document, how to test?

   srowen: send it to the mailinglist, another todo

   dom: how to document the expected result?

   srowen: another todo

   <srowen> TODO add document mapping tests to description and
   coniditon tested

   all: good job (applause)

   - pause -

   jo: review where we are with external libraries
   ... jhove, utf-8 and other stuff

   srowen: working with the utf8 validation, returning line numbers

   abel: the css validation returns errors not in a exception

   srowen: we should display the errors from the third party library

   <abel> study about third parties error reporting
   -->[11]http://docs.google.com/Doc?docid=dhbw7zt7_0f8w6bq

     [11] http://docs.google.com/Doc?docid=dhbw7zt7_0f8w6bq

   jo: [discussion about using external libraries]
   ... libraries are written for production mode and not to analyze
   errors

   <srowen> think we are talking about 3 things:

   <jo> TODO write up lessons learned in some form

   <srowen> 1) bugs and faults in libraries that hurt us. actually I
   don't know that we were hit significantly by bugs

   <srowen> 2) libraries don't give much attention to error cases, and
   they are usually concerned with the non-error case (e.g. a generic
   exception is thrown if anything goes wrong). Not a fault in the
   general sense but yes a problem for us

   <srowen> I think we should file feature requests and so forth
   'formally' for projects that might usefully improve their support
   for tools

   <srowen> specifically should file bugs/requests against CSS
   validator

   <srowen> 3) finally i would like to see any of our outstanding
   to-dos or bugs tracked in tracker rather than only in a document so
   that they are live, publicly visible, trackable, assignable

   <srowen> ... but writing a doc in addition to all this never hurts
   too

   srowen: going back to the agenda
   ... using the tracker system
   ... resolving issues and track features and bugs

   <dom> [12]Bugs recorded for the mobileOK checker

     [12] http://www.w3.org/Bugs/Public/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=mobileOK+Basic+checker&content=

   srowen: other agenda items?

   <dom> [13]Open and Pending Action Items for the checker TF

     [13] http://www.w3.org/2005/MWI/BPWG/Group/track/products/10

   <nacho> ScribeNick: nacho

Review open actions from last F2F

   dom: ACTION-505 ... done and info sent to the list

   <dom> [14]my mail on action 505

     [14] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Jul/0085.html

   <dom> [15]Sean's analysis of licenses

     [15] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Jul/0091.html

   [discussion about licensing of the checker taking into account that
   it depends on 3rd party libraries]

   <dom>
   [16]http://lists.w3.org/Archives/Public/public-mobileok-checker/2007
   Aug/0000.html

     [16] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Aug/0000.html

   <dom> and
   [17]http://lists.w3.org/Archives/Public/public-mobileok-checker/2007
   Aug/0008.html

     [17] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Aug/0008.html

   <dom> "we can indeed distribute the unmodified libraries provided we
   do so with the right license notice."

   dom: ACTION-505 closed

   Sean: legalOK and dotMobi
   ... any problem about contributing your work under W3C ?

   jo: no

   nacho: i do not think so... formal answer next Friday

   roland: it is important to have the company's name shown and a
   disclaimer about responsabilities for the result of contributed code

   sean: good point to be included in the docs (user and dev manuals)
   ... ACTION-509

   <dom> see
   [18]http://lists.w3.org/Archives/Public/public-mobileok-checker/2007
   Jul/0085.html re ACTION-509

     [18] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Jul/0085.html

   dom: maybe copyright statement should change a little bit to include
   reference to companies contributing... a thing to be studied

   sean: let's leave ACTION-509 open

   <dom> I opened ACTION-542 to replace ACTION-509

   sean: license of each external library being used is included in the
   project at the moment and also a COPYRIGHT.html
   ... with COPYRIGHT.html being actually the license... so i will
   rename it
   ... ACTION-510

   miguel: the problem is solved... ACTION-510 to be closed

   sean: ACTION-511

   [19]http://lists.w3.org/Archives/Public/public-mobileok-checker/2007
   Jun/0044.html

     [19] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Jun/0044.html

   sean: ACTION-511 closed
   ... ACTION-512

   roland: no XPath function available

   sean: 02 ACTION-51201 closed
   ... ACTION-512
   ... ACTION-513
   ... done as seen in
   [20]http://lists.w3.org/Archives/Public/public-mobileok-checker/2007
   Jun/0046.html
   ... ACTION-513 to be closed

     [20] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Jun/0046.html

   [sean summarizes details about current implementation about char
   encoding]

   <dom> [21]http://www.w3.org/TR/2006/REC-xml-20060816/#sec-guessing

     [21] http://www.w3.org/TR/2006/REC-xml-20060816/#sec-guessing

   [discussion about XML Header and how its characters are represented
   in different encodings]

   dom: my last URL was for XML prolog header Detection Without
   External Encoding Information

   <dom> TODO fix character encoding detection in XML

   ACTION-513 is closed with last TODO from Dom pending

   sean: ACTION-514

   <scribe> ... done
   .ACTION-514 to be closed

   sean: ACTION-515

   abel: closed

   sean: ACTION-516

   dom: done

   sean: ACTION-517
   ... effectively done

   jo: caching when resolving DTDs?

   miguel: CatalogResolved configured in properties file...

   sean: good configuration and DTD caching done
   ... ACTION-518

   [sean speaks about TesterConfiguration public class]

   <dom> TODO Check what happens and decide what should happen when an
   unknown DTD is referenced

   sean: TODO improve TesterConfiguration class
   ... ACTION-519

   nacho: my POVs about the docs were commented yesterday... 1st drafts
   in 1 week or 2

   [dom sets a new deadline substituting the one that nacho missed O:-)
   ]

Open Issues

   sean: ISSUE-209

   <dom> ACTION-543 created for perf analysis

   lunch break

   we are back!

   <dom> [22]http://www.w3.org/2007/09/04-mobileok-minutes.html

     [22] http://www.w3.org/2007/09/04-mobileok-minutes.html

   <dom> ScribeNick: ruadhan

   <dom> Extracted Todos:

   <dom> : complete test on extraneous characters

   <dom> : add "about me" node (info about implementation libraries,
   versions, etc)

   <dom> : missing namespaced in parsed/tidy document

   <dom> : show whether the parsed document has been tidied

   <dom> : encoding output not showing properly

   <dom> : modify moki not to say "fail" for warns on CSS (distinguish
   errors from warnings)

   <dom> : complete stylesheet_use to pick up the warnings

   <dom> : omit <column> when column undetermined

   <dom> : deal with inline stylesheets

   <dom> : delete stylesheetssupporttest.xsl

   <dom> : Cahce Control test (and others) should only be carried out
   on the final redirect of any particular request

   <dom> : Results need to be labelled with the document that they are
   moaning about if it is not the primary doc

   <dom> : deal properly with GET forms (i.e. include empty/default
   values for each form element)

   <dom> : implementing CSS parsing for extraenous white space

   <dom> need to come up with working example for adding line number in
   XSL-based tests

   <dom> track the CSS cascade issue as a known issue

   <dom> add ability to run one test at a time

   sean: lets look at todos

   <dom> : check that each warn/fail condition is minimally tested by
   our test suite

   <dom> build a way save test run results as the golden test result

   <dom> add document mapping tests to description and coniditon tested

   <dom> write up lessons learned in some form

   <dom> fix character encoding detection in XML

   <dom> Check what happens and decide what should happen when an
   unknown DTD is referenced

   <dom> improve TesterConfiguration class

   sean: extraneous characters - lets treat as action item

   <dom> ACTION-544 created

   <dom> (to deal with white space)

   <dom> ACTION-545 created for sean to deal with about-me

   sean: "about information" sean will take as action
   ... missing namespace - track it as a bug

   <dom>
   [23]http://www.w3.org/Bugs/Public/enter_bug.cgi?product=mobileOK%20B
   asic%20checker

     [23] http://www.w3.org/Bugs/Public/enter_bug.cgi?product=mobileOK%20Basic%20checker

   <dom> [24]http://www.w3.org/Bugs/Public/

     [24] http://www.w3.org/Bugs/Public/

   [all create bugzilla account]

   sean: show whether parsed doc has been tidied - treat as bug
   ... encoding output - filed as bug
   ... css fail/warning issue - filed as bug

   <jo> HONY SOYT QUI MAL EVENCE

   <jo> Should be

   <jo> Honi soit qui mal y pense

   [further TODOs added added to bugzilla]

   Roland: WRT checking form actions, there is an issue with multiple
   submit buttons in forms

   <dom> [I added the link to our bug lists from the checker task force
   home page]

   jo: WRT to checking state of warn/fail conditions in test suite -
   hold off until next draft is completed

   <dom>
   [25]http://www.w3.org/Bugs/Public/buglist.cgi?query_format=specific&
   order=relevance+desc&bug_status=__all__&product=mobileOK+Basic+check
   er&content=

     [25] http://www.w3.org/Bugs/Public/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=mobileOK+Basic+checker&content=

   sean: we've alotted todos, and we still need to complete tests
   ... miletsones - work towards alpha release, fix any major bugs
   ... doesn't need to be perfect but should be ready for conference in
   November
   ... rough alpha release in 5 weeks, early-mid October

   dom: after alpha we should think about a simple web interface so we
   can demonstrate

   <dom> Created ACTION-548 - Set up simple web interface on top of
   Java library for Alpha release [on Dominique Hazaƫl-Massieux - due
   2007-09-12].

   sean: is this a realistic timeline?

   miguel: still the issue of https certification

   sean: i propose we put something out by October 12th
   ... all tests written, at least one test case for each condition,
   and major bugs are addressed
   ... just needs to be respectable
   ... there is a conference 4 weeks after this date that we should
   have something nice for

   <srowen> PROPOSED RESOLUTION: Release 1.0 alpha on October 12. All
   tests implemented, with minimal regression tests, all P1 bugs fixed

   <srowen> RESOLUTION: Release 1.0 alpha on October 12. All tests
   implemented, with minimal regression tests, all P1 bugs fixed

   <srowen> PROPOSED RESOLUTION: Release 1.0 beta on Nov. 13 at Mobile
   Internet World. All P1 bugs fixed. More regression tests implemented
   by this point. Alpha web interface available at
   validator.w3.org/mobile/...

   <srowen> RESOLUTION: Release 1.0 beta on Nov. 13 at Mobile Internet
   World. All P1 bugs fixed. More regression tests implemented by this
   point. Alpha web interface available at validator.w3.org/mobile/...

   sean: maybe tack on day at next BPWG meeting

   jo: that might be tough

   sean: let's play it by ear
   ... maybe next F2F in late January
   ... any other issues or concerns?

Summary of Action Items

   [End of minutes]
Received on Wednesday, 5 September 2007 13:44:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 December 2014 20:11:46 UTC