See also: minutes Day 1 | IRC log
<dom> ScribeNick: roland
sean: agenda for today
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
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 http://localhost:8080/StyleSheetsUseTest/2/index.xhtml FWIW]
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 -->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> Bugs recorded for the mobileOK checker
srowen: other agenda items?
<dom> Open and Pending Action Items for the checker TF
<nacho> ScribeNick: nacho
dom: ACTION-505 ... done and info sent to the list
<dom> my mail on action 505
<dom> Sean's analysis of licenses
[discussion about licensing of the checker taking into account that it depends on 3rd party libraries]
<dom> http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Aug/0000.html
<dom> and 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 http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Jul/0085.html re ACTION-509
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
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
http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Jun/0046.html
... ACTION-513 to be closed
[sean summarizes details about current implementation about char encoding]
<dom> 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
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:-) ]
sean: ISSUE-209
<dom> ACTION-543 created for perf analysis
lunch break
we are back!
<dom> 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> http://www.w3.org/Bugs/Public/enter_bug.cgi?product=mobileOK%20Basic%20checker
<dom> 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
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?