mobileOK checker Task Force F2F, day 1

 

 

<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 http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/070824

<dom> mobileOK Basic latest editors draft

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> someone complaining about the markup validator not following meta-refresh (and life, universe , and everything)

<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> 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> > http://docs.google.com/View?docid=dgh5r6zs_5cb7gz3 mobileOK test implementation on google docs

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 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

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 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