See also: Day 2 minutes | IRC log
<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)
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]
<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