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

[minutes] Checker F2F Day 1 (Sep 4)

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 05 Sep 2007 14:17:29 +0200
To: public-mobileok-checker <public-mobileok-checker@w3.org>
Message-Id: <1188994649.30754.3.camel@cumulustier>


The (drafty) minutes of our meeting yesterday are available at:
linked from:

and copied as text below.


                mobileOK checker Task Force F2F, day 1

4 Sep 2007


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

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

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


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





     * [5]Topics
         1. [6]Agenda
         2. [7]Review of Laura's work
     * [8]Summary of Action Items

   <scribe> Meeting: BPWG Checker Task Force, Sophia Antipolis, Day 1

   <scribe> scribe: Jo


   Sean: Today mostly about where we are and raising issues and
   problems, things we need to get done
   ... tomorrow about solving and prioritizing issues
   ... Thursday about doing some collaborative work
   ... agenda edited due to late start (roundabout factor)

Review of Laura's work

   Sean: Think Laura did the following tests:

   <srowe1> 3.1 AUTO_REFRESH (partial) and REDIRECTION

   <srowe1> 3.2 CACHING



   <srowe1> 3.5 DEFAULT_INPUT_MODE

   <srowe1> 3.6 EXTERNAL_RESOURCES

   <srowe1> 3.7 GRAPHICS_FOR_SPACING

   <srowe1> 3.8 IMAGE_MAPS


   <srowe1> 3.11 MEASURES

   <srowe1> 3.20 STYLE_SHEETS_SUPPORT (partial)

   sean: need to review in detail but think they are substantially
   working, good job, probably ready for Beta
   ... some of the issues that came up:
   ... overall test application - command line runner
   ... let's try it against google
   ... really slow start up 10-15 secs
   ... shouldn't be this slow
   ... [raises issue]

   Ruadhan: installed resolver for DTDs so shouldn't be that

   Sean: looks at moki doc

   jo: need to resolve how multiple references to the same thing is
   handled in moki doc

   Sean: think that is done

   jo: need to refer to where the reference is that causes an image to
   ... e.g. an image that is retrieved by an imported style sheet that
   imports a style sheet

   dom: parsing errors won't pick this up

   jo: need to state what the rule is for equivalence of URIs
   ... just needs to be stated and document

   sean: I think this complicates the code considerably more than it

   jo: I think it is important from the point of helping implementors
   find out e.g. where something has gone wrong and why a document has
   been retrieved

   dom: we should at least record the source document if not from the
   line number
   ... think this would be useful

   Jo: think that we should make an issue about recording the line no
   and source document that caused a retrieval

   [sean raises ISSUE-210]

   jo: should I make the HTTP thing a separate namespace

   dom: no lets keep it simple for now

   jo: we should make the element names MarkupValidity and
   MobileValidity more clearly different
   ... more meaningful

   [sean raises ISSUE-211]

   sean: be aware of the knock-on effect on style sheets
   ... everything will need to be checked for references

   Abel: extraneous characters are not being checked properly yet

   Sean: do we have a problem with the character encoding?

   <dom> TODO: complete test on extraneous characters

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

   <dom> TODO: missing namespaced in parsed/tidy document

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

   <dom> TODO: encoding output not showing properly

   -> editors draft

      [9] http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/070824

   <dom> [10]mobileOK Basic latest editors draft

     [10] http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/070824

   Sean: hover is invalid CSS?

   jo: it's not CSS 1 - anyway it shouldnot say 'invalid' it reults
   only in a warn

   sean: yes we should probably make it consistent and not say it is a

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

   <dom> TODO: complete stylesheet_use to pick up the warnings

   <dom> TODO: omit <column> when column undetermined

   [discussion about the fact that we don't ever have a column no so
   should be omitted for clarity]

   <dom> Abel: we're not checking inline styles at this time

   <dom> ... we can have a look at this

   <dom> TODO: deal with inline styles defined in attributes

   sean: we should check for style attribute when running the XSLT

   abel: we can put stylesheet type as "inline" or something

   jo: it would make more sense to have the CSS results all in one

   sean: but it is, having stuff in the moki document is merely a

   <dom> TODO: delete stylesheetssupporttest.xsl

   <dom> [the latter is done]

   miguel: stylesheetsupport.xsl was for when we serialised it as XML

   sean: issue about finding line and column

   dom: we should just do our best efforts as there is only one line in
   attributes anyway

   <dom> (and they can only be in the markup document, by definition)

   sean: should we just make this an inline type in the moki without
   line number

   [Agreed that thiswould be the approach]

   Sean: links ... we don't have the body in the moki document

   jo: we cant look at meta if we don't have the body

   Sean: we should at least look at this to see what it is doing
   ... need to check whether the body is omitted on links a) because it
   is application/xhtml or b) because the charset was already specified
   so there is no need for the body
   ... so the question is when should the body be recorded
   ... a) we should record bodies despite the bloat
   ... b) we should not record unknown or binary
   ... c) not for link targets either

   [jo raised an issue on LINK_TARGET_FORMAT, ISSUE-212 making clear
   that the document body does not need to be examined]

   [raised ISSUE-213 on objects etc ]

   RESOLUTION: Record the body only of external CSS

   TODO: Cache Control test (and others) should only be carried out on
   the final redirect of any particular request
   ... Results need to be labelled with the document that they are
   moaning about if it is not the primary doc

   Sean: meta refresh

   jo: I think we should stop if we see refresh because the rest of the
   results are bogus

   sean: I think we should just leave it as it is

   [Sean raises ISSUE-214 on whether it is sensible to stop or not]

   <dom> [11]someone complaining about the markup validator not
   following meta-refresh (and life, universe , and everything)

     [11] http://lists.w3.org/Archives/Public/www-validator/2003Jul/0174.html

   <j1> [continuing after lunch]

   <j1> Sean: let's carry on with looking at the moki document

   <j1> ... should we use copy of text in the tests document or edited
   a bit

   <j1> ... OK that's about it from me, I am going to get a bit more
   involved from now

   <dom> ScirbeNick: srowe1

   <j1> Scribenick: Sean

   <dom> ScirbeNick: srowe1

   <j1> scribenick: srowe1

   roland: finished all my tests but STYLE_SHEETS_USE-5 and

   focused on XSLT and not junit tests

   have been using moki and saxon+xslt, writing success and failure

   have problems running the test implementation

   srowe1: only need to run 'ant'

   roland: yes, tests fail

   need to wait until tests don't fail

   srowe1: should be basically runinng, building now so report problems
   to list

   roland: can also write junit tests

   srowe1: should not need to write junit tests if not writing java

   roland: rename functions.xsl to common.xsl?

   dom: seems Ok to leave it as is

   roland: xpath and moki document may not explain the test. need to
   include references to mobileok basic document

   leads us to discuss ids and names

   latest draft has IDs in document

   need to agree on naming convention

   don't see, where is the test_ syntax used?

   the IDs in the new basic tests draft

   (much discussion about current conventions)

   PROPOSED RESOLUTION: change 'test_x' anchors in mobileOK Basic doc
   to 'X'

   PROPOSED RESOLUTION: for tests related to multiple BPs, use the name
   of the first one (e.g. AUTO_REFRESH, not AUTO_REFRESH_REDIRECTION)

   PROPOSED RESOLUTION: leave current fragment identifiers for any test
   conditions that don't directly map to best practices

   RESOLUTION: change 'test_x' anchors in mobileOK Basic doc to 'X'
   ... for tests related to multiple BPs, use the name of the first one
   ... leave current fragment identifiers for any test conditions that
   don't directly map to best practices

   roland: being consistent lets one automatically look for differences
   between mobileOK Basic document and test output
   ... some tests do not have xhtml namespaces


     [12] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Jul/0080

   srowe1: solving html xmlns problem will solve this problem too

   roland: laura finished some tests -- who owns her tests now?

   srowe1: I will

   let's look at the status in the google doc

   dom: let's distinguish between coding done and test suites complete

   <dom> > [13]http://docs.google.com/View?docid=dgh5r6zs_5cb7gz3
   mobileOK test implementation on google docs

     [13] http://docs.google.com/View?docid=dgh5r6zs_5cb7gz3

   let's update the document

   I can own the first 9 now, all should be completed


   roland: by 'finished' I mean 'coding done' -- will update

   srowe1: roland, sounds like status is you have written
   implementations in xslt but haven't been able to write tests

   roland: yes and have found some bugs / unnecessarily complicated
   expressions in XSL, and fixed those

   topics for tomorrow - what will happen when mobileOK goes live?
   bugs, maintenance, etc.?

   srowe1: think we need a bug tracker for people to report bugs. I
   will try to stay involved after release and hope everyone can. what

   roland: yes, what are next steps?

   <dom> [I have added a mobileok checker product in
   [14]http://www.w3.org/Bugs/Public/ ]

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

   srowe1: how are we going to put this out with a public web
   interface, to get a lot of usage and see bugs?

   not sure ready.mobi can just use this since it will be buggy

   ruadhan: could put out a beta version for people to use 'at their
   own risk'

   would have to run by james

   j1: not clear how comprehensive the tests we have here are

   not sure we have all positive and negative tests for tests

   srowe1: yes full regression test suite is essential

   how about putting this up as a beta at validator.w3.org/mobile?

   dom: yes as soon as performance issues are solved. can wrap the java
   library in python

   critical to a) implement all tests and b) fix performance first

   the more we have regression tests the better I feel

   srowe1: think we need to first finish this (plus performance issues)
   and write regression tests

   then put it up at w3.org, let it prove itself, collect bugs

   then have ruadhan look at ready.mobi beta based on it

   look at differences with current implementation to find more bugs

   but that's not on the radar yet

   roland: when we launch a service there are many administrative
   concerns like errors, logs, performance. who will monitor this?

   dom: won't be a problem, I will be administering initially

   <dom> we have a reservation for tonight at:

   <dom> Restaurant la Daurade

   <dom> 44 bd Aguillon

   <dom> 06600 Antibes

   abel: LINK_TARGET_FORMAT has some issues

   miguel: https connections can be handled by apache http client, but
   mobileOK basic tests say in 2.3.3,

   we have to check certificate validity and so on

   not sure if http client handles invalid certificate

   need to implement socket connection to see if certificate is valid
   or not

   but don't stop test

   srowe1: is the issue just checking for certificate expiration?

   miguel: note that client will accept self-signed certificates, good

   srowe1: client will fail fast if HTTPS certificate is invalid

   the TODO concerns handling expired certificates

   miguel: need to define how to request forms with GET

   for linked results, we need at least <meta> information to carry out
   consistence of content type test

   srowe1: first point is about forms. you are noting that we are not
   handling form inputs with actual values when GETting the form action

   dom: yes we would need to do that. But I think we should not handle
   forms at all

   this is just for a warn, after all

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

   dom: parsing the input elements and forming URI is not so bad

   (digression on name "Visible Linked Resources")

   miguel: I think we will get back errors of blank pages in response
   many times

   dom: yes, results are likely to be useless

   j1: all we are looking for is content type really, not results
   ... difference between HEAD and GET

   dom: according to HTTP should return the same headers

   j1: all we care about is content type

   miguel: we will usually just get errors anyway

   we aren't testing the "real" case anyway

   can get different pages in response to a form

   srowe1: a bit better to request the form properly so we're more
   likely to test a 'real' case. Can never test all cases.

   dom: just seems like a bunch of effort for little

   j1: will catch a small but useful number of cases, like using a form
   for a push-button when it could be a hyperlink

   srowe1: miguel your other point was the same we discussed this
   morning -- whether we need to keep body of linked resources?

   related to ISSUE-212


     [15] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/212

   srowe1: not an issue if we decide to not examine body of linked

   miguel: MINIMIZE

   still need to exclude pre, style, script, etc.

   also need to not use Character.isWhitespace()

   roland: why do we exclude style and script?

   j1: we could re-serialize CSS and compare with original to detect
   extra whitespace

   srowe1: is whitespace ever significant?

   in CSS?

   dom: a string literal with multiple spaces, for example, shouldn't
   be counted against the page in <script> -- not extraneous

   roland: whitespace in URIs in CSS?

   dom: should have to be escaped
   ... content element is an example where string literals may be found
   in CSS
   ... fine to leave it as is

   j1: CSS quoting mechanism could be an issue

   dom: I think this will introduce more bugs -- leave it to
   implementations to note CSS whitespace

   srowe1: I don't think quoting quotes/spaces is a problem here

   I think it's just one more line in the test

   on the other hand, most of the waste of whitespace is not in CSS

   j1: ... it's in change history block comments...

   srowe1: ... indenting markup with spaces...

   dom: don't we need to then parse whitespace in external stylesheets

   roland: if PAGE_SIZE_LIMIT fails, we could note this may be due to
   large script or style elements, to solve this, and not change the

   <dom> css parsing for comments "COMMENT

   srowe1: kind of convinced that it's not worth it

   j1: ironic that simple things like "parsing CSS comments" sound "too
   hard" to purported experts

   <dom> css parsing for comments in css 2.1 "COMMENT

   j1: need to consider script and style together

   I suppose script doesn't necessarily contain javascript or any
   particular language

   althought it's almost surely javascript

   srowe1: think script is too hard to deal with

   j1: ... proposes thought experiment about page with script that
   overwrites itself with a simple message on load

   should write something in mobileOK about pathological cases to fool
   the tester

   dom: mobileOK only worth something to people trying to do the right
   thing anyway, so many pathological use cases

   that it's not useful describe any one of them

   dom: let's not bother about <style> now. can leave this to

   (much more debate about this)

   srowe1: vote for modifying mobileOK basic and implementing this

   (straw poll supported this)

   dom: what are the rules? fail on whitespace count on a per-document

   srowe1: yes

   we will raise an issue on this

   <dom> TODO: implementing CSS parsing for extraenous white space

   nacho: let's discuss user manual content

   <dom> " \t\r\n\f"

   <dom> \f, see [16]http://en.wikipedia.org/wiki/Page_break

     [16] http://en.wikipedia.org/wiki/Page_break

   nacho: will start working on documentation as an OpenOffice doc,
   upload to repository

   is it preferable in XML?

   srowe1: markup might be more desirable since it can be put online
   but really not a big deal

   just use OpenOffice for now

   j1: whatever's easiest -- it would be nice to turn this into markup

   nacho: how to be represented in the cover of the document? logos?

   srowe1: just names and organization names

   j1: use format used on mobileOK Basic test doc, where we list
   editors / primary contributors, and list other acknowledgements

   srowe1: everyone in this room is a primary contributor, plus Laura

   j1: wonder if James et al. should be acknowledged

   nacho: list license in the doc?

   dom: I have open actions about copyright

   j1: copyright of document is separate from copyright of code

   also issue of whether derivate works can be called 'mobileOK checker

   dom: then again we're only a client of the mobileOK group's output,
   which kind of owns tha tname

   j1: need to note this though

   dom: need to clear it with working group to be called the reference

   srowe1: not necessarily true that any derivative work *isn't*
   checking mobileOK -- depends on whether tests implement the spec

   j1: attention needs to be called to this

   nacho: first section is an introduction

   explain the audience

   people using the library as well as developers using, say, a web

   explain relation to mobileOK test document

   plus hyperlinks to document

   explain web interface and how to use it in next section

   srowe1: there is no UI with the library, though
   validator.w3.org/mobile will probably use it

   dom: question is, what is the audience?

   I think we should focus on the library and not a UI

   srowe1: yes, would not worry about the UI yet

   j1: we should produce a downloadable .jar file which can be urn on
   the command line

   srowe1: yes easy to produce a standalone runnable .jar file,
   'statically linked'

   nacho: OK so focus on library

   want to make sure people that only find the document can quickly
   play with the test suite

   library section would first focus on how to load and start it

   srowe1: that should be very easy

   j1: question about whether version of libraries changing affects
   mobileOK compliance

   srowe1: we can't know -- the reference implementation with its given
   versions is 'official' and that's about all we can say

   nacho: next need to explain public methods, API, configuration

   need to explain moki format

   nacho: finally, section with code snippets and examples

   simple examples, or more complex?

   srowe1: one comprehensive example showing complete usage of the Java
   API sounds good to me

   j1: we should link to public-mobileok-checker list and home page

   nacho: next section is architectural overview

   also explain here how the design tries to stay independent of
   libraries and so on

   next section includes UML use case diagrams to show how flows work

   srowe1: how useful are UML sequence diagrams? maybe a high-level
   diagram at best

   j1: maybe a class interaction diagram

   nacho: also want to include section on design, design patterns

   maybe a package diagram?

   srowe1: it's all in one package

   j1: maybe separate out preprocessor classes?

   nacho: next section explains tests, which tests the library passes

   dom: maybe it should be a section about how to add new test test

   srowen1: I think the writing tests-for-tests section is by far the
   most important for developers working on the library itself

   nacho: lastly, section on performance

   dom: not obvious what to put in there now

   srowe1: yeah I would wait until there is something substantive we
   need to say about performance

Summary of Action Items

   [End of minutes]
Received on Wednesday, 5 September 2007 12:18:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:19 UTC