- 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>
Hi,
The (drafty) minutes of our meeting yesterday are available at:
http://www.w3.org/2007/09/04-mobileok-minutes.html
linked from:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Checker/Overview.html
and copied as text below.
Dom
mobileOK checker Task Force F2F, day 1
4 Sep 2007
[2]Agenda
[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
Attendees
Present
Sean, Dom, Nacho, Roland, Ruadhan, Abel, Miguel, Jo
Regrets
None
Chair
Sean
Scribe
Jo
Contents
* [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
Agenda
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.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
<srowe1> 3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP
<srowe1> 3.5 DEFAULT_INPUT_MODE
<srowe1> 3.6 EXTERNAL_RESOURCES
<srowe1> 3.7 GRAPHICS_FOR_SPACING
<srowe1> 3.8 IMAGE_MAPS
<srowe1> 3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE
<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
retrieved
... 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
seems
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-T
ests/070824
[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
fail
<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
(style='background-image:url()')
<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
place
sean: but it is, having stuff in the moki document is merely a
convenience
<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
OBJECTS_OR_SCRIPT-6
focused on XSLT and not junit tests
have been using moki and saxon+xslt, writing success and failure
tests
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
code
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
(e.g. AUTO_REFRESH, not AUTO_REFRESH_REDIRECTION)
... 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
<dom>
[12]http://lists.w3.org/Archives/Public/public-mobileok-checker/2007
Jul/0080
[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
plus MEASURES STYLE_SHEETS_SUPPORT
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
else?
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
URI
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
[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
resources
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
tests
<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
implementations.
(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
basis?
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
automatically
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
elsewhere
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
implementation
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
interface
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
cases
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