IRC log of mobileok on 2007-09-04

Timestamps are in UTC.

07:12:15 [RRSAgent]
RRSAgent has joined #mobileok
07:12:15 [RRSAgent]
logging to http://www.w3.org/2007/09/04-mobileok-irc
07:12:19 [Zakim]
Zakim has joined #mobileok
07:12:25 [dom]
RRSAgent, make log public
07:12:38 [dom]
Meeting: mobileOK checker Task Force F2F, day 1
08:29:13 [roland]
roland has joined #mobileok
08:36:58 [jo]
jo has joined #mobileok
08:37:11 [srowen]
srowen has joined #mobileok
08:37:33 [jo]
jo has changed the topic to: BPWG Roundabout Engineering Task FOrce
08:37:48 [jo]
jo has changed the topic to: BPWG Roundabout Engineering Task Force
08:38:32 [jo]
Chair: Sean
08:38:54 [jo]
Meeting: BPWG Checker Task Force, Sophia Antipolis, Day 1
08:39:03 [jo]
scribe: Jo
08:39:07 [jo]
scribenick: jo
08:39:18 [jo]
rrsagent, make logs public
08:39:25 [jo]
rrsagent, draft minutes
08:39:25 [RRSAgent]
I have made the request to generate http://www.w3.org/2007/09/04-mobileok-minutes.html jo
08:44:37 [srowe1]
srowe1 has joined #mobileok
08:44:46 [srowe1]
Testing
08:45:53 [jo]
jo has joined #mobileok
08:45:55 [srowe1]
srowe1 has joined #mobileok
08:46:22 [jo]
Present: Sean, Dom, Nacho, Roland, Ruadhan, Abel, Miguel, Jo
08:46:31 [jo]
RRSAgent, draft minutes
08:46:32 [RRSAgent]
I have made the request to generate http://www.w3.org/2007/09/04-mobileok-minutes.html jo
08:47:15 [jo]
Topic: Agneda
08:47:23 [jo]
s/Agneda/Agenda
08:47:53 [jo]
Sean: Today mostly about where we are and raising issues and problems, things we need to get done
08:48:12 [jo]
... tomorrow about solving and prioritizing issues
08:48:26 [jo]
... Thursday about doing some collaborative work
08:48:35 [jo]
rrsagent, please draft minutes
08:48:35 [RRSAgent]
I have made the request to generate http://www.w3.org/2007/09/04-mobileok-minutes.html jo
08:49:45 [srowe1]
Agenda: http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Aug/0084.html
08:50:14 [abel]
abel has joined #mobileok
08:50:17 [jo]
Sean: agenda edited due to late start (roundabout factor)
08:50:20 [miguel]
miguel has joined #mobileok
08:50:25 [jo]
Topic: Review of Laura's work
08:50:26 [miguel]
miguel has left #mobileok
08:50:52 [jo]
Sean: Think Laura did the following tests:
08:51:05 [srowe1]
3.1 AUTO_REFRESH (partial) and REDIRECTION
08:51:05 [srowe1]
3.2 CACHING
08:51:05 [srowe1]
3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
08:51:05 [srowe1]
3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP
08:51:05 [srowe1]
3.5 DEFAULT_INPUT_MODE
08:51:06 [srowe1]
3.6 EXTERNAL_RESOURCES
08:51:08 [srowe1]
3.7 GRAPHICS_FOR_SPACING
08:51:10 [srowe1]
3.8 IMAGE_MAPS
08:51:10 [miguel]
miguel has joined #mobileok
08:51:12 [srowe1]
3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE
08:51:14 [srowe1]
3.11 MEASURES
08:51:16 [srowe1]
3.20 STYLE_SHEETS_SUPPORT (partial)
08:51:50 [jo]
sean: need to review in detail but think they are substantially working, good job, probably ready for Beta
08:52:00 [jo]
... some of the issues that came up:
08:52:24 [jo]
... overall test application - command line runner
08:52:35 [jo]
... let's try it against google
08:52:48 [jo]
... really slow start up 10-15 secs
08:54:14 [ruadhan]
ruadhan has joined #mobileok
08:55:28 [jo]
... shouldn't be this slow
08:55:34 [jo]
... [raisis issue]
08:55:43 [jo]
s/raisis/raises/
08:56:08 [jo]
Ruadhan: installed resolver for DTDs so shouldn't be that
08:56:32 [jo]
Sean: looks at moki doc
08:57:28 [jo]
jo: need to resolve how multiple references to the same thing is handled in moki doc
08:57:42 [jo]
Sean: think that is done
08:59:28 [jo]
jo: need to refer to where the reference is that causes an image to retrieved
08:59:52 [jo]
... e.g. an image that is retrieved by an imported style sheet that imports a style sheet
09:00:11 [jo]
dom: parsing errors won't pick this up
09:01:05 [jo]
jo: need to state what the rule is for equivalence of URIs
09:01:22 [jo]
... just needs to be stated and document
09:05:11 [jo]
sean: I think this complicates the code considerably more than it seems
09:06:07 [jo]
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
09:06:30 [jo]
dom: we should at least record the source document if not from the line number
09:06:36 [jo]
... think this would be sueful
09:06:42 [jo]
s/sueful/useful/
09:07:47 [jo]
Jo: think that we should amke an issue about recording the line no and source document that caused a retrieval
09:07:56 [jo]
s/amke/make/
09:08:21 [dom]
dom has joined #mobileok
09:08:25 [nacho]
nacho has joined #mobileok
09:09:00 [jo]
[sean raises ISSUE-210]
09:10:09 [jo]
jo: should I make the HTTP thing a spearate namespace
09:10:20 [jo]
dom: no lets keep it simple for now
09:10:37 [jo]
s/spearate/separate/
09:12:41 [jo]
jo: we should make the element names MarkupValidity and MobileValidity more clearly different
09:12:49 [jo]
... more meaningful
09:13:19 [jo]
[sean raises ISSUE-211]
09:14:16 [jo]
sean: be aware of the knock-on effect on style sheets
09:14:38 [jo]
... everything will need to be checked for references
09:14:57 [jo]
Abel: extraneous characters are not being checked properly yet
09:22:10 [jo]
Sean: do we have a problem with the character encoding?
09:23:29 [dom]
TODO: complete test on extraneous characters
09:23:45 [dom]
TODO: add "about me" node (info about implementation libraries, versions, etc)
09:23:57 [dom]
TODO: missing namespaced in parsed/tidy document
09:24:43 [dom]
TODO: show whether the parsed document has been tidied
09:24:58 [dom]
TODO: encoding output not showing properly
09:25:29 [jo]
-> editors draft http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/070824
09:25:54 [nacho]
nacho has joined #mobileok
09:25:59 [dom]
-> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/070824 mobileOK Basic latest editors draft
09:27:06 [jo]
Sean: hover is invalid CSS?
09:27:30 [jo]
jo: it's not CSS 1 - anyway it shouldnot say 'invalid' it reults only in a warn
09:28:30 [jo]
sean: yes we should probably make it consistent and not say it is a fail
09:29:17 [dom]
TODO: modify moki not to say "fail" for warns on CSS (distinguish errors from warnings)
09:29:27 [dom]
TODO: complete stylesheet_use to pick up the warnings
09:31:54 [dom]
TODO: omit <column> when column undetermined
09:32:27 [jo]
[discussion about the fact that we don't ever have a column no so should be omitted for clarity]
09:33:26 [dom]
Abel: we're not checking inline styles at this time (style='background-image:url()')
09:33:36 [dom]
... we can have a look at this
09:34:13 [dom]
TODO: deal with inline stylesheets
09:34:33 [dom]
s/stylesheets/styles defined in attributes/
09:38:33 [Zakim]
Zakim has left #mobileok
09:38:43 [jo]
sean: we should check for style attribute when running the XSLT
09:39:50 [jo]
abel: we can put stylesheet type as "inline" or something
09:40:36 [jo]
jo: it would make more sense to have the CSS results all in one place
09:40:54 [jo]
sean: but it is, having stuff in the moki document is merely a conveience
09:41:11 [jo]
convenience
09:41:26 [jo]
s/conveience/convenience
09:41:41 [jo]
s/convenience//
09:43:49 [dom]
TODO: delete stylesheetssupporttest.xsl
09:44:37 [dom]
[the latter is done]
09:44:44 [jo]
miguel: stylesheetsupport.xsl was for when we serialised it as XML
09:46:09 [jo]
sean: issue about finding line and column
09:46:30 [jo]
dom: we should just do our best efforts as there is only one line in attributes anyway
09:46:46 [dom]
(and they can only be in the markup document, by definition)
09:47:22 [jo]
sean: should we just make this an inline type in the moki without line number
09:47:26 [dom]
RRSAgent, draft minutes
09:47:26 [RRSAgent]
I have made the request to generate http://www.w3.org/2007/09/04-mobileok-minutes.html dom
09:47:33 [jo]
[Agrred that thiswould be the approach]
09:47:48 [jo]
s/Agrred/Agreed/
09:50:52 [nacho_]
nacho_ has joined #mobileok
09:52:22 [jo]
Sean: links ... we don't have the body in the moki document
09:52:56 [jo]
jo: we cant look at meta if we don't have the body
09:53:17 [jo]
Sean: we should at least look at this to see what it is doing
09:53:18 [nacho]
nacho has joined #mobileok
09:54:11 [nacho]
nacho has joined #mobileok
09:54:19 [jo]
... 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
09:54:37 [jo]
sean: so the question is when should the body be recorded
09:55:03 [jo]
... a) we should record bodies despite the bloat
09:55:18 [jo]
... b) we should not record unknown or binary
09:59:56 [nacho_]
nacho_ has joined #mobileok
10:01:30 [nacho]
nacho has joined #mobileok
10:03:26 [jo]
.. c) not for link targets either
10:04:57 [jo]
[jo raised an issue on LINK_TARGET_FORMAT, ISSUE-212 making clear that the document body does not need to be examined]
10:12:17 [jo]
[raised ISSUE-213 on objects etc ]
10:12:46 [jo]
RESOLUTION: Record the body only of external CSS
10:13:27 [nacho_]
nacho_ has joined #mobileok
10:17:12 [jo]
TODO: Cahce Control test (and others) should only be carried out on the final redirect of any particular request
10:17:45 [jo]
TODO: Results need to be labelled with the document that they are moaning about if it is not the primary doc
10:18:00 [jo]
s/Cahce/Cache/
10:24:23 [jo]
Sean: meta refresh
10:24:47 [jo]
jo: I think we should stop if we see refresh because the rest of the results are bougus
10:24:58 [jo]
s/bougus/bogus/
10:25:38 [jo]
sean: I think we should just leave it as it is
10:29:00 [nacho]
nacho has joined #mobileok
10:29:17 [jo]
[Sean raises ISSUE-214 on whether it is sensible to stop or not]
10:39:08 [dom]
dom has joined #mobileok
10:39:35 [dom]
-> http://lists.w3.org/Archives/Public/www-validator/2003Jul/0174.html someone complaining about the markup validator not following meta-refresh (and life, universe , and everything)
10:40:52 [RRSAgent]
I have made the request to generate http://www.w3.org/2007/09/04-mobileok-minutes.html dom
11:38:41 [dom]
dom has joined #mobileok
11:40:36 [miguel]
miguel has joined #mobileok
11:42:57 [j1]
j1 has joined #mobileOK
11:46:28 [j1]
[continuing after lunch]
11:46:39 [j1]
Sean: let's carry on with looking at the moki document
11:48:19 [j1]
... should we use copy of text in the tests document or edited a bit
11:48:26 [miguel]
miguel has joined #mobileok
11:48:36 [j1]
... let's leave it alone
11:50:29 [j1]
... OK that's about it from me, I am going to get a bit more involved from now
11:50:39 [dom]
ScirbeNick: srowe1
11:50:49 [j1]
Scribenick: Sean
11:51:04 [dom]
ScirbeNick: srowe1
11:51:07 [j1]
scribenick: srowe1
11:53:15 [srowe1]
roland: finished all my tests but STYLE_SHEETS_USE-5 and OBJECTS_OR_SCRIPT-6
11:54:01 [srowe1]
focused on XSLT and not junit tests
11:54:10 [nacho]
nacho has joined #mobileok
11:54:40 [srowe1]
have been using moki and saxon+xslt, writing success and failure tests
11:55:16 [srowe1]
have problems running the test implementation
11:55:30 [srowe1]
srowe1: only need to run 'ant'
11:55:38 [srowe1]
roland: yes, tests fail
11:55:57 [srowe1]
need to wait until tests don't fail
11:56:29 [srowe1]
srowe1: should be basically runinng, building now so report problems to list
11:57:35 [srowe1]
roland: can also write junit tests
11:58:35 [srowe1]
srowe1: should not need to write junit tests if not writing java code
11:58:53 [srowe1]
roland: rename functions.xsl to common.xsl?
11:59:35 [srowe1]
dom: seems Ok to leave it as is
12:00:15 [srowe1]
roland: xpath and moki document may not explain the test. need to include references to mobileok basic document
12:00:33 [srowe1]
leads us to discuss ids and names
12:00:53 [srowe1]
latest draft has IDs in document
12:01:25 [srowe1]
need to agree on naming convention
12:04:32 [srowe1]
don't see, where is the test_ syntax used?
12:04:49 [srowe1]
the IDs in the new basic tests draft
12:10:32 [srowe1]
(much discussion about current conventions)
12:11:17 [srowe1]
PROPOSED RESOLUTION: change 'test_x' anchors in mobileOK Basic doc to 'X'
12:12:27 [srowe1]
PROPOSED RESOLUTION: for tests related to multiple BPs, use the name of the first one (e.g. AUTO_REFRESH, not AUTO_REFRESH_REDIRECTION)
12:15:55 [srowe1]
PROPOSED RESOLUTION: leave current fragment identifiers for any test conditions that don't directly map to best practices
12:17:58 [srowe1]
RESOLUTION: change 'test_x' anchors in mobileOK Basic doc to 'X'
12:18:05 [srowe1]
RESOLUTION: for tests related to multiple BPs, use the name of the first one (e.g. AUTO_REFRESH, not AUTO_REFRESH_REDIRECTION)
12:18:10 [srowe1]
RESOLUTION: leave current fragment identifiers for any test conditions that don't directly map to best practices
12:18:40 [srowe1]
roland: being consistent lets one automatically look for differences between mobileOK Basic document and test output
12:19:32 [srowe1]
roland: some tests do not have xhtml namespaces
12:20:15 [dom]
http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Jul/0080
12:21:44 [srowe1]
srowe1: solving html xmlns problem will solve this problem too
12:22:04 [srowe1]
roland: laura finished some tests -- who owns her tests now?
12:22:06 [srowe1]
srowe1: I will
12:23:00 [srowe1]
let's look at the status in the google doc
12:23:12 [srowe1]
dom: let's distinguish between coding done and test suites complete
12:24:18 [dom]
> http://docs.google.com/View?docid=dgh5r6zs_5cb7gz3 mobileOK test implementation on google docs
12:25:33 [srowe1]
let's update the document
12:25:39 [srowe1]
I can own the first 9 now, all should be completed
12:26:42 [srowe1]
plus MEASURES STYLE_SHEETS_SUPPORT
12:26:52 [srowe1]
roland: by 'finished' I mean 'coding done' -- will update
12:28:50 [srowe1]
srowe1: roland, sounds like status is you have written implementations in xslt but haven't been able to write tests
12:29:11 [srowe1]
roland: yes and have found some bugs / unnecessarily complicated expressions in XSL, and fixed those
12:30:32 [srowe1]
topics for tomorrow - what will happen when mobileOK goes live? bugs, maintenance, etc.?
12:31:55 [srowe1]
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?
12:32:03 [srowe1]
roland: yes, what are next steps?
12:33:15 [dom]
I have added a mobileok checker product in http://www.w3.org/Bugs/Public/ ]
12:33:21 [dom]
s/I/[I/
12:33:31 [srowe1]
srowe1: how are we going to put this out with a public web interface, to get a lot of usage and see bugs?
12:34:04 [srowe1]
not sure ready.mobi can just use this since it will be buggy
12:34:28 [srowe1]
ruadhan: could put out a beta version for people to use 'at their own risk'
12:35:07 [srowe1]
would have to run by james
12:35:47 [srowe1]
j1: not clear how comprehensive the tests we have here are
12:36:14 [srowe1]
not sure we have all positive and negative tests for tests
12:36:23 [srowe1]
srowe1: yes full regression test suite is essential
12:37:45 [srowe1]
how about putting this up as a beta at validator.w3.org/mobile?
12:38:03 [srowe1]
dom: yes as soon as performance issues are solved. can wrap the java library in python
12:38:31 [srowe1]
critical to a) implement all tests and b) fix performance first
12:38:41 [srowe1]
the more we have regression tests the better I feel
12:42:22 [srowe1]
srowe1: think we need to first finish this (plus performance issues) and write regression tests
12:42:34 [srowe1]
then put it up at w3.org, let it prove itself, collect bugs
12:42:44 [srowe1]
then have ruadhan look at ready.mobi beta based on it
12:42:54 [srowe1]
look at differences with current implementation to find more bugs
12:43:00 [srowe1]
but that's not on the radar yet
12:44:21 [srowe1]
roland: when we launch a service there are many administrative concerns like errors, logs, performance. who will monitor this?
12:44:57 [srowe1]
dom: won't be a problem, I will be administering initially
12:48:10 [RRSAgent]
I have made the request to generate http://www.w3.org/2007/09/04-mobileok-minutes.html dom
13:15:23 [roland]
roland has joined #mobileok
13:18:39 [dom]
we have a reservation for tonight at:
13:18:39 [dom]
Restaurant la Daurade
13:18:39 [dom]
44 bd Aguillon
13:18:39 [dom]
06600 Antibes
13:28:44 [srowe1]
abel: LINK_TARGET_FORMAT has some issues
13:29:27 [srowe1]
miguel: https connections can be handled by apache http client, but mobileOK basic tests say in 2.3.3,
13:29:39 [srowe1]
we have to check certificate validity and so on
13:30:33 [srowe1]
not sure if http client handles invalid certificate
13:30:52 [srowe1]
need to implement socket connection to see if certificate is valid or not
13:31:08 [srowe1]
but don't stop test
13:34:32 [srowe1]
srowe1: is the issue just checking for certificate expiration?
13:34:48 [srowe1]
miguel: note that client will accept self-signed certificates, good
13:36:20 [srowe1]
srowe1: client will fail fast if HTTPS certificate is invalid
13:38:51 [srowe1]
the TODO concerns handling expired certificates
13:39:30 [srowe1]
miguel: need to define how to request forms with GET
13:40:11 [srowe1]
for linked results, we need at least <meta> information to carry out consistence of content type test
13:42:00 [srowe1]
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
13:42:12 [srowe1]
dom: yes we would need to do that. But I think we should not handle forms at all
13:43:42 [srowe1]
this is just for a warn, after all
13:52:55 [dom]
TODO: deal properly with GET forms (i.e. include empty/default values for each form element)
13:53:15 [srowe1]
dom: parsing the input elements and forming URI is not so bad
13:53:34 [srowe1]
(digression on name "Visible Linked Resources")
13:53:49 [srowe1]
miguel: I think we will get back errors of blank pages in response many times
13:54:02 [srowe1]
dom: yes, results are likely to be useless
13:54:13 [srowe1]
j1: all we are looking for is content type really, not results
13:54:41 [srowe1]
j1: difference between HEAD and GET
13:54:54 [srowe1]
dom: according to HTTP should return the same headers
13:55:13 [srowe1]
j1: all we care about is content type
13:55:30 [srowe1]
miguel: we will usually just get errors anyway
13:56:09 [srowe1]
we aren't testing the "real" case anyway
13:56:29 [srowe1]
can get different pages in response to a form
13:57:30 [srowe1]
srowe1: a bit better to request the form properly so we're more likely to test a 'real' case. Can never test all cases.
13:57:49 [srowe1]
dom: just seems like a bunch of effort for little
13:58:10 [srowe1]
j1: will catch a small but useful number of cases, like using a form for a push-button when it could be a hyperlink
14:01:01 [srowe1]
srowe1: miguel your other point was the same we discussed this morning -- whether we need to keep body of linked resources?
14:02:18 [srowe1]
related to ISSUE-212
14:02:19 [srowe1]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/212
14:03:11 [srowe1]
srowe1: not an issue if we decide to not examine body of linked resources
14:03:39 [srowe1]
miguel: MINIMIZE
14:04:12 [srowe1]
still need to exclude pre, style, script, etc.
14:08:23 [srowe1]
also need to not use Character.isWhitespace()
14:08:32 [srowe1]
roland: why do we exclude style and script?
14:09:10 [srowe1]
j1: we could re-serialize CSS and compare with original to detect extra whitespace
14:09:18 [srowe1]
srowe1: is whitespace ever significant?
14:09:24 [srowe1]
in CSS?
14:10:14 [srowe1]
dom: a string literal with multiple spaces, for example, shouldn't be counted against the page in <script> -- not extraneous
14:10:22 [srowe1]
roland: whitespace in URIs in CSS?
14:10:27 [srowe1]
dom: should have to be escaped
14:11:54 [srowe1]
dom: content element is an example where string literals may be found in CSS
14:11:57 [srowe1]
dom: fine to leave it as is
14:16:14 [srowe1]
j1: CSS quoting mechanism could be an issue
14:16:29 [srowe1]
dom: I think this will introduce more bugs -- leave it to implementations to note CSS whitespace
14:16:42 [srowe1]
srowe1: I don't think quoting quotes/spaces is a problem here
14:17:52 [srowe1]
I think it's just one more line in the test
14:19:25 [srowe1]
on the other hand, most of the waste of whitespace is not in CSS
14:19:35 [srowe1]
j1: ... it's in change history block comments...
14:19:51 [srowe1]
srowe1: ... indenting markup with spaces...
14:20:20 [srowe1]
dom: don't we need to then parse whitespace in external stylesheets
14:21:55 [srowe1]
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
14:23:58 [dom]
css parsing for comments "COMMENT \/\*[^*]*\*+([^/][^*]*\*+)*\/"
14:25:11 [srowe1]
srowe1: kind of convinced that it's not worth it
14:25:59 [srowe1]
j1: ironic that simple things like "parsing CSS comments" sound "too hard" to purported experts
14:27:05 [dom]
css parsing for comments in css 2.1 "COMMENT \/\*[^*]*\*+([^/*][^*]*\*+)*\/"
14:27:20 [srowe1]
j1: need to consider script and style together
14:27:44 [srowe1]
I suppose script doesn't necessarily contain javascript or any particular language
14:27:54 [srowe1]
althought it's almost surely javascript
14:28:00 [srowe1]
srowe1: think script is too hard to deal with
14:28:56 [srowe1]
j1: ... proposes thought experiment about page with script that overwrites itself with a simple message on load
14:29:51 [srowe1]
should write something in mobileOK about pathological cases to fool the tester
14:30:18 [srowe1]
dom: mobileOK only worth something to people trying to do the right thing anyway, so many pathological use cases
14:30:28 [srowe1]
that it's not useful describe any one of them
14:35:54 [srowe1]
dom: let's not bother about <style> now. can leave this to implementations.
14:42:43 [srowe1]
(much more debate about this)
14:42:56 [srowe1]
srowe1: vote for modifying mobileOK basic and implementing this
14:43:02 [srowe1]
(straw poll supported this)
14:44:43 [srowe1]
dom: what are the rules? fail on whitespace count on a per-document basis?
14:44:47 [srowe1]
srowe1: yes
14:46:59 [srowe1]
we will raise an issue on this
14:47:29 [dom]
TODO: implementing CSS parsing for extraenous white space
14:49:30 [srowe1]
nacho: let's discuss user manual content
15:07:45 [dom]
" \t\r\n\f"
15:08:54 [dom]
\f, see http://en.wikipedia.org/wiki/Page_break
15:12:18 [srowe1]
nacho: will start working on documentation as an OpenOffice doc, upload to repository
15:12:26 [srowe1]
is it preferable in XML?
15:13:01 [srowe1]
srowe1: markup might be more desirable since it can be put online but really not a big deal
15:13:25 [srowe1]
just use OpenOffice for now
15:13:41 [srowe1]
j1: whatever's easiest -- it would be nice to turn this into markup automatically
15:13:42 [RRSAgent]
I have made the request to generate http://www.w3.org/2007/09/04-mobileok-minutes.html dom
15:14:41 [srowe1]
nacho: how to be represented in the cover of the document? logos?
15:14:59 [srowe1]
srowe1: just names and organization names
15:16:26 [srowe1]
j1: use format used on mobileOK Basic test doc, where we list editors / primary contributors, and list other acknowledgements elsewhere
15:16:39 [srowe1]
srowe1: everyone in this room is a primary contributor, plus Laura
15:16:51 [srowe1]
j1: wonder if James et al. should be acknowledged
15:17:04 [srowe1]
nacho: list license in the doc?
15:17:23 [srowe1]
dom: I have open actions about copyright
15:17:57 [srowe1]
j1: copyright of document is separate from copyright of code
15:18:19 [srowe1]
also issue of whether derivate works can be called 'mobileOK checker
15:18:53 [srowe1]
dom: then again we're only a client of the mobileOK group's output, which kind of owns tha tname
15:18:59 [srowe1]
j1: need to note this though
15:19:16 [srowe1]
dom: need to clear it with working group to be called the reference implementation
15:20:14 [srowe1]
srowe1: not necessarily true that any derivative work *isn't* checking mobileOK -- depends on whether tests implement the spec
15:20:19 [srowe1]
j1: attention needs to be called to this
15:21:27 [srowe1]
nacho: first section is an introduction
15:21:32 [srowe1]
explain the audience
15:21:52 [srowe1]
people using the library as well as developers using, say, a web interface
15:22:01 [srowe1]
explain relation to mobileOK test document
15:22:18 [srowe1]
plus hyperlinks to document
15:22:48 [srowe1]
explain web interface and how to use it in next section
15:24:05 [srowe1]
srowe1: there is no UI with the library, though validator.w3.org/mobile will probably use it
15:24:10 [srowe1]
dom: question is, what is the audience?
15:24:35 [srowe1]
I think we should focus on the library and not a UI
15:25:09 [srowe1]
srowe1: yes, would not worry about the UI yet
15:25:25 [srowe1]
j1: we should produce a downloadable .jar file which can be urn on the command line
15:26:27 [srowe1]
srowe1: yes easy to produce a standalone runnable .jar file, 'statically linked'
15:26:32 [srowe1]
nacho: OK so focus on library
15:27:29 [srowe1]
want to make sure people that only find the document can quickly play with the test suite
15:27:45 [srowe1]
library section would first focus on how to load and start it
15:27:58 [srowe1]
srowe1: that should be very easy
15:29:04 [srowe1]
j1: question about whether version of libraries changing affects mobileOK compliance
15:29:28 [srowe1]
srowe1: we can't know -- the reference implementation with its given versions is 'official' and that's about all we can say
15:29:37 [srowe1]
nacho: next need to explain public methods, API, configuration
15:29:45 [srowe1]
need to explain moki format
15:31:06 [srowe1]
nacho: finally, section with code snippets and examples
15:31:49 [srowe1]
simple examples, or more complex?
15:33:01 [srowe1]
srowe1: one comprehensive example showing complete usage of the Java API sounds good to me
15:33:32 [srowe1]
j1: we should link to public-mobileok-checker list and home page
15:34:19 [srowe1]
nacho: next section is architectural overview
15:35:17 [srowe1]
also explain here how the design tries to stay independent of libraries and so on
15:35:44 [srowe1]
next section includes UML use case diagrams to show how flows work
15:36:27 [srowe1]
srowe1: how useful are UML sequence diagrams? maybe a high-level diagram at best
15:36:35 [srowe1]
j1: maybe a class interaction diagram
15:37:03 [srowe1]
nacho: also want to include section on design, design patterns
15:37:33 [srowe1]
maybe a package diagram?
15:37:38 [srowe1]
srowe1: it's all in one package
15:38:59 [srowe1]
j1: maybe separate out preprocessor classes?
15:39:36 [srowe1]
nacho: next section explains tests, which tests the library passes
15:39:53 [srowe1]
dom: maybe it should be a section about how to add new test test cases
15:41:21 [srowe1]
srowen1: I think the writing tests-for-tests section is by far the most important for developers working on the library itself
15:41:29 [srowe1]
nacho: lastly, section on performance
15:42:02 [srowe1]
dom: not obvious what to put in there now
15:42:17 [srowe1]
srowe1: yeah I would wait until there is something substantive we need to say about performance
15:43:13 [RRSAgent]
I have made the request to generate http://www.w3.org/2007/09/04-mobileok-minutes.html dom
15:45:26 [dom]
44 bd Aguillon
15:45:26 [dom]
06600 Antibes
15:46:14 [j1]
j1 has left #mobileok
15:46:43 [abel]
abel has left #mobileok
15:48:17 [miguel]
miguel has left #mobileok
16:23:37 [nacho]
nacho has left #mobileok