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

[minutes] London F2F Dat 1, June 12

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 13 Jun 2007 15:08:27 +0100
To: public-mobileok-checker <public-mobileok-checker@w3.org>
Message-Id: <1181743708.14035.8.camel@cumulustier>

Hi

The minutes of our meeting yesterday are available at:
http://www.w3.org/2007/06/12-bpwg-minutes.html

and copied as text below (say "Hi" to trackbot).

Dom

[1]W3C

      [1] http://www.w3.org/

                mobileOK ref implementation F2F, day 1

12 Jun 2007

   [2]Agenda

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

   See also: [3]IRC log

      [3] http://www.w3.org/2007/06/12-bpwg-irc

Attendees

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

   Chair
          Jo, Sean

   Scribe
          dom, Jo, roland

Contents

     * [4]Topics
         1. [5]Goals for the F2F
         2. [6]licensing and IPR
         3. [7]issues with XSLT Framework, standardization of output
            format
         4. [8]Result format
         5. [9]error reporting, error codes and I18N
         6. [10]Results Format Continued
         7. [11]Result Document - In summary
     * [12]Summary of Action Items
     _________________________________________________________



Goals for the F2F

   Jo: we made quite good progress

   ... there is already quite a lot of code

   ... I think we ought to think of several things

   ... code quality (esp. mine!)

   Jo: acceptance criteria of the BPWG as a whole to endorse our work
   ... probably a combination of test suites that shows that it has
   reached a reasonable level of quality
   ... which means we need to think about our testing period
   ... We probably should also do an audit of how much work there is
   left
   ... esp as summer is coming up, and people (incl me) will be taking
   time off
   ... Overall, really happy about the progress of the group

   abel: a few points that will need to be discussed based on our work
   ... caching behavior of the checker
   ... how to deal with CSS? We haven't picked a CSS library yet
   ... we'll also need to define an exception hierarchy
   ... also need to work on how to handle messages that come from third
   party libraries

   Jo: indeed, third party messages will be tricky to handled
   ... e.g. for I18N
   ... We'll certainly have to revisit this subject
   ... TagSoup doesn't look too hard to modify

   Abel: not all libraries provide error codes

   Roland: I hope that we'll get to better define the results document
   ... would like to make sure it's easy to check a page against the
   checker: providing examples, ways of fixing code, etc.

   Jo: is this in scope for our work?
   ... MobiReady checker has this, from .mobi
   ... CTIC could do the same
   ... I don't know we need to develop this in this group
   ... it's probably good that each implementation can add what's
   needed on top of the common answer all the tools should give
   ... I don't think it's in scope for this group

   Roland: we have to define unique ids to allow other tools to build
   on top of ours, then

   Jo: indeed; it is similar to Abel's concern re error codes
   ... The question is how much information do we need to provide to
   make this possible

   Nacho: I think we need to map error codes and messages to an
   unambiguous code provided by moki
   ... hopefully with a declarative approach

   Roland: I think a minimal set of error codes and examples would be
   useful
   ... we're not interested in providing a mobileOK checker, but we
   want to make sure our system produces mobileOK pages
   ... that's why we're interested to make sure there is a single
   mobileOK answer

   Ruadhan: I would like to get a clear plan what we still need to work
   on
   ... also, the current XSLT framework makes it hard to report several
   failures

   dom: error message is going to be tricky and we need to use the time
   to solve that here rather than on this phone
   ... should be a priority for the meeting
   ... also set up test suite and it should be done sooner rather than
   later,
   ... I would like to help with the XSLT too

   Jo: another concern I have: we need to pay attention on licensing,
   copyright notices, etc
   ... we need to make sure for instance that Jhove's license is
   compatible with our usage
   ... we may need to engage some legal help at some point
   ... [summarizing the additional points suggested for the agenda]
   ... * error reporting, error codes and I18N
   ... * test suites, and acceptance criteria, beta period
   ... * licensing and IPR
   ... * issues with XSLT Framework, standardization of output format
   ... * CSS Library
   ... * Exceptions hierarchy
   ... * Cacheing behavior

   Roland: another question: mobileOK refers often to the HTTP Request
   headers in 2.3.2, but the list doesn't seem to be complete

   Jo: It is actually complete
   ... this was under discussion on the public mailing list recently,
   btw
   ... interesting points that were not made before

   ->
   [13]http://lists.w3.org/Archives/Public/public-bpwg-comments/2007Apr
   Jun/0033.html Laurens Host on Accept header in mobileOK

     [13] http://lists.w3.org/Archives/Public/public-bpwg-comments/2007AprJun/0033.html

   <roland>
   [14]http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-
   Tests/070520#test_objects_or_script refers to 2.3.2 HTTP Request
   headers

     [14] http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/070520#test_objects_or_script

   Dom: re HTTP Accept, we should look at what most current mobile
   browsers do
   ... if most do as Laurens suggest, we should probably that approach
   ... but I don't believe mobileOK basic should mandate one way or the
   other in any case

   Jo: right; I think HTTP certainly doesn't forbid to send the whole
   thing for each request

   Roland: [discussing the reference to http request headers in
   objects_or_script in mobileOK Basic]

   Jo: the tests are indeed a bit inconsistent in terms of the
   reference to the accepted types
   ... that said, I'm trying to keep the changes as small as possible

   ->
   [15]http://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a
   _module_Object DTD of object module, showing that "type" attribute
   is not required on <object />

     [15] http://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a_module_Object

   Dom: note that the type attribute is not mandatory, re test on
   objects_or_script

   <scribe> ACTION: Jo to get back to BPWG on objects_or_script with
   regard to type attribute on object element [recorded in
   [16]http://www.w3.org/2007/06/12-bpwg-minutes.html#action01]

   <trackbot> Created ACTION-504 - Get back to BPWG on
   objects_or_script with regard to type attribute on object element
   [on Jo Rabin - due 2007-06-19].

licensing and IPR

   Jo: the first thing to check is whether we can redistribute
   according to our license
   ... to do so, we would need to call on legal advice
   ... probably should be done by W3C legal team

   Dom: seems fair, as long as we provide them with a definitive list
   of packages and licenses

   <scribe> ACTION: Dom to give a heads up to legal team re IPR, check
   if there is anything we should carefully avoid [recorded in
   [17]http://www.w3.org/2007/06/12-bpwg-minutes.html#action02]

   <trackbot> Created ACTION-505 - Give a heads up to legal team re
   IPR, check if there is anything we should carefully avoid [on
   Dominique Hazael-Massieux - due 2007-06-19].

   Jo: Another question we need to ask ourselves is: what do we want?
   :)
   ... obviously we want all the usual open source stuff: free to use,
   redistribute, with preservation of credits and licensing
   ... do we want to allow people to modify it?

   Dom: if we want to call it open source, we have to

   Jo: my only concern with it is it would allow people to change the
   code and provide modifiefd mobileoK checker services

   dom: we can protect this through the trademark on W3C mobileOK basic
   ... not sure we can enforce the usage of the ref implementation;
   most likely, should we enforce anything, it would be based on a
   conformance test suite
   ... much like Java
   ... still, we should allow people to re-use our code (e.g. for other
   libraries), propose bug fixes and so on

   Jo: test suite sounds good
   ... we want one for our own needs, anyway
   ... we would need some versioning with it, obviously
   ... I guess the BPWG will need to look at the question of licensing
   of mobileOK

   Dom: for the checker, I think the working group will need to endorse
   a test suite as a reference test suite

   Jo: we probably need legal advice on how to make sure the words
   "mobileOK checker" is protected

   Dom: it's already protected through our trademark, although we'll
   certainly need legal advice on how to put it in words
   ... I think the W3C Software License would cover most of our needs
   ... W3C has also a process to allow for external contributors
   ... I guess contributions could be sent to our mailing list
   (public-mobileok-checker)
   ... provided we keep maintaining the code - but W3C, CTIC and
   dotMobi have their on-line services based on the library, there is
   no reason to worry for the foreseeable future
   ... the key question would be the maintenance process of the
   conformance test suite for checkers
   ... would probably need some input for the BPWG as whole

   Jo: what about credits?

   Dom: two different things: credits in the code, vs credits in
   distributed binary versions
   ... Requiring credits for binaries that use our code would make our
   license much less OSS-friendly

   Jo: we should check each with our own organizations

   <scribe> ACTION: Jo to check with dotMobi that W3C Software license
   is legalOK [recorded in
   [18]http://www.w3.org/2007/06/12-bpwg-minutes.html#action03]

   <trackbot> Created ACTION-506 - Check with dotMobi that W3C Software
   license is legalOK [on Jo Rabin - due 2007-06-19].

   <scribe> ACTION: Ignacio to check with CTIC that W3C Software
   license is legalOK [recorded in
   [19]http://www.w3.org/2007/06/12-bpwg-minutes.html#action04]

   <trackbot> Created ACTION-507 - Check with CTIC that W3C Software
   license is legalOK [on Ignacio Marn - due 2007-06-19].

   <scribe> ACTION: Roland to check with 7Val that W3C Software license
   is legalOK [recorded in
   [20]http://www.w3.org/2007/06/12-bpwg-minutes.html#action05]

   <trackbot> Created ACTION-508 - Check with 7Val that W3C Software
   license is legalOK [on Roland Guelle - due 2007-06-19].

   <scribe> ACTION: Dom to check how to make the names of the companies
   appear in the copyright statement [recorded in
   [21]http://www.w3.org/2007/06/12-bpwg-minutes.html#action06]

   <trackbot> Created ACTION-509 - Check how to make the names of the
   companies appear in the copyright statement [on Dominique
   Hazael-Massieux - due 2007-06-19].

issues with XSLT Framework, standardization of output format

   <roland> ScribeNick: roland

   ruadhan: if there are more errors in one test, it is difficult to
   handle these errors
   ... when provide defaults fails, you can only report the first

   <dom> miguel: the current code only takes care of the first result
   element

   <dom> ... we probably need to make it possible to report more than
   one failure

   <dom> ... I guess we should calculate from the java code what is the
   complete outcome of the results

   <dom> ... (i.e. if there is any failures reported, the outcome is
   fail; if not, it is pass)

   roland: the problem is the java implementation, there is no problem
   with the xslt

   <dom> ACTION: Ignacio to annoy Miguel until he implements the change
   to java implementation to deal with reporting more than one failure
   [recorded in
   [22]http://www.w3.org/2007/06/12-bpwg-minutes.html#action08]

   <trackbot> Created ACTION-510 - Annoy Miguel until he implements the
   change to java implementation to deal with reporting more than one
   failure [on Ignacio Marn - due 2007-06-19].

   dom: so we can move to the output format

   abel: the parameter language is to change for the messages

   dom: should we add a settings file for the XSLT?

   jo add this to the agenda

   <jo> scribenick: jo

Result format

   roland: standardization of the output format
   ... based on format from Sean's initial test - limited and needs
   changing
   ... need to change the format according to this example

   [roland shows an example]

   roland: the test reference is the BP ID
   ... need a sub-reference to mobileOK test
   ... within the test each possible FAIL or warn needs an ID

error reporting, error codes and I18N

   <dom> (XSLT output format and error reporting are obviously strongly
   bound)

   <dom> [discussing about what the results document should contain,
   e.g. a copy of moki or not]

Results Format Continued

   Sean: minimal document we discussed before lunch was ..

   Roland: why don't we copy more info fromthe moki document to make it
   independent

   ruadhan: like code snippets?

   dom: well the way to make a choice could be to think about the use
   cases - I like this apporach, which is simple and keeps the
   localization in one place
   ... but the basic question is what we want the results document to
   be ...
   ... e.g. to integrate into an authoring tool this is not enough.
   ... e.g. line col needed to highlight the error

   sean: use cases, Authoring Tools, IDE;
   ... Online Tool like validator.w3.org/mobile
   ... some comand line utility
   ... important use case is tool

   jo: what about mobileoK accrditation

   sean: the last is the least demanding

   dom: the tool case only demands the line and column

   jo: it doesn't need to be friendly to users just usable by
   developers so I suggest
   ... we do all or nothing - the minimum being that we record the
   results for the tests and some minimal info about where you have
   failed if you have failed
   ... or you include the whole molki output and tell developer that if
   that's not what they want they can alter the code

   sean: agree with the result doc lining up with the mok basic doc

   dom: what about line col - this is not in the moki doc?

   jo: ah, I see your point, but how will we get that anyway

   dom: we haven't figured that out yet (sic)

   <Zakim> dom, you wanted to ask about how to provide location
   information with XSLT

   dom: the question is how do we actually get than information from
   xslt which has no notion - that said (TM) I do think we should have
   the location information, the difficulty is that xslt doesn't tell
   us where the error is
   ... for example, if there is a basefont etc. xslt won't tel you
   where
   ... not possible in xlst 1 but I don't think you can do it in xslt 2

   roland: you could step through the whole document node by node

   dom: that would only work if you ...

   roland: we are not interested in text nodes so whitespace doesn't
   matter

   jo: I missed the point that you were making roland

   roland: select name from each node and create an absolute xpath

   dom: need some magic to turn xpath into a line col

   sean: need some facotry that allows you to tell for any Dom element
   where it came from

   jo: should we go away and see if someone has solved this problem
   before?

   roland: when we get a fail, generate an xpath to thelement that
   failed

   dom: but what we want to give is line col not xpath

   roland: so we match the code in the document and find the code in
   the source document
   ... in the post processing ...

   dom: but that doesn't work if there are duplicates in the document

   jo: let's annotate each line with a comment then the line number is
   the preceding sibling

   everyone: oh god that is terribly hacky

   jo: so?

   [dom then goes on to explain why it doesn't work as well as being
   very tacky]

   [discussion of how people use SAX to get the information]

   jo: I remember that the MS parser does this

   ruadhan: yes something in .net and python too

   sean: well it can be done ...

   ... we do need to ask someone to research this

   dom: and it needs to be found out sooner ratherthan later

   ... we could "remain silent" on the line and column no and just give
   the xpath and leave the problem to implementors

   sean: there must be some way to do it ...

   dom: we should be open to the idea of replacing the xslt with sax
   parsing if that is what it takes

   ... but before that we should action someone to find out

   ... if we can get this from xpath

   ACTION: Sean research annotations in the Dom giving the source line
   and column number [recorded in
   [23]http://www.w3.org/2007/06/12-bpwg-minutes.html#action09]

   <trackbot> Created ACTION-511 - Research annotations in the Dom
   giving the source line and column number [on Sean Owen - due
   2007-06-19].

   ACTION: Roland to research getting line and column information from
   XPath [recorded in
   [24]http://www.w3.org/2007/06/12-bpwg-minutes.html#action10]

   <trackbot> Created ACTION-512 - Research getting line and column
   information from XPath [on Roland Guelle - due 2007-06-19].

   Roland: want to build a regex to match foo/@bar

   dom: doesn't work ...

   roland: ok

   dom: one option going from xpath to line/col is sax - you do end up
   parsing again

   sean: so assuming we can get the line/col what should we put in the
   result document?

   dom: [explains facing the board hiding what he is writing]

   <dom> <position type="document|header|linecolumn" url="(markup or
   css or image">

   sean: there are 4 ways to elaborate the position:

   <dom> subelement or attributes: row/column, headername

   ... no position (refers to the whole), header, line col and url in
   addition

   jo: don't we need line col in headers too?

   dom: well I'd prefer not

   sean: if we showed the header value then that would be enough

   ... would not refer to images etc.

   dom: could add a rank to clarify in the case of a duplciate HTTP
   header

   ... need to provide the bare minimum to provide useful stuff

   ... i.e. not code snippets

   sean: so how about we miss out the code snippet?

   nacho: not needed

   abel:if it is an image then we need byte offset

   jo: yes, and for character encoding errors

   <dom> [25]Pointer methods in rDF

     [25] http://www.w3.org/WAI/ER/Pointers/WD-Pointers-20070222

   [sean explores various possibilities]

   [dom points out that its easier to work with an explicit byte
   offset]

   nacho: it would be better to have an xpath location to tie back to
   the moki document

   ... we do the xpath first

   ... then if we find a way of doing the line and column do it later

   dom: Ok, but I think it needs line/col though it might speed up
   development

   sean: agree with Dom - need line col to orginal document

   jo: point out that the origianl document and the current resource at
   the URI and question are not necessarily the same

   ... so think that if you want to reference you need to reference the
   moki document

Result Document - In summary

   [conversation went off-road at this point]

   [discussions on how to get the position of the errors from XSLT]

   <ruadhan> line & column from xpath?

   <ruadhan> [26]http://www3.telus.net/minevskiy/ivan/project_XPath.htm

     [26] http://www3.telus.net/minevskiy/ivan/project_XPath.htm

   [discussions on whether browsers download several times a
   non-cacheable image loaded several time in a single page]

   <dom> [27]random image with no-cache

     [27] http://www-mit.w3.org/2007/06/test-no-cache.php

   <roland> [28]http://www.xml.com/pub/a/2004/11/24/py-xml.html, File
   Locations from SAX

     [28] http://www.xml.com/pub/a/2004/11/24/py-xml.html

   <dom> [29]demonstration of using three times an uncached resource

     [29] http://www.w3.org/2007/06/test-html-no-cache.html

   <dom> <dom> Yves, if an image with a no-cache directive is loaded
   three times in the same page, should a browser makes three separate
   http requests, or is it "normal" not to? is there anywhere where
   this "in-memory" caching would be specified?

   <dom> <ChrisL> dom - yes it should

   <dom> <dom> my observation is at least that firefox doesn't

   <dom> <Yves> there is no "in memory" caching. HTTP specifies
   no-cache and no-store

   <dom> <Yves> <dom> do you have an answer to the first part of my
   question, Yves? :)

   <dom> <Yves> <Yves> not really as it mixes two things, HTTP
   interactions (in that case, yes it should do multiple requests)

   <dom> <Yves> and HTML parsing, where the client can have one
   reference to external objects and say that all the references to the
   same object leads to only one in memory

   <dom> <Yves> in that case it is valid to generate only one HTTP
   request

   <dom> <Yves> so the right answer for your question is "undecided"

   <dom> <Yves> unless there is a processing model defined for HTML :)

   <dom> (new tests in
   [30]http://www.w3.org/2007/06/test-html-no-cache.html , include
   hex-encoded URIs which at least Firefox makes a separate request
   for)

     [30] http://www.w3.org/2007/06/test-html-no-cache.html

   <dom> (and my Blazer User Agent doesn't normalize port :80 mentions,
   while Firefox does)

   [massive digression on tidying the character encoding]

   <dom> "You can also supply an AutoDetector that peeks at the
   incoming byte stream and guesses a character encoding for it.
   Otherwise, the platform default is used. If you need an autodetector
   of character sets, consider trying to adapt the Mozilla one; if you
   succeed, let me know." [31]http://ccil.org/~cowan/XML/tagsoup/

     [31] http://ccil.org/~cowan/XML/tagsoup/

   <dom> [32]IconV package in Java

     [32] http://www.docjar.org/docs/api/gnu/java/nio/charset/iconv/

   [resuming discussion of what needs to go in the minimal document]

   We resolved ref tidying as follows:

   (All designed in a way that allows others to contribute trial
   decodings)

   1. Get the document

   2. Determine stated character encoding - look at in order
   content-type, xml dec and meta

   2a if it claims to be UTF-8 tidy if necessary by inserting
   replacement char

   2b If it claims to be something other than UTF-8

   Try converting it using appropriate tool

   2c If it makes no claim - treat it as a utf-8 byte stream and add
   replacement chars where necessary

   3. HTML Validate with xxx

   3a. if invalid tidy

   The tidied document is hence either character encoding tidying or
   HTML tidying and the tests need to point out that they are working
   on tidied versions where they are.

   Dom said he'd give implementing it a shot.

   ACTION: Dom to give implementing character encoding thingy a shot
   [recorded in
   [33]http://www.w3.org/2007/06/12-bpwg-minutes.html#action11]

   <trackbot> Created ACTION-513 - Give implementing character encoding
   thingy a shot [on Dominique Hazael-Massieux - due 2007-06-19].

   We resolved that the result document format was as follows:

   one position per result

   if necessary repeat result for each error

   <info> message is parameterised

   <roland> [34]example of what a results document looks like

     [34] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Jun/att-0030/moki_transformation_example.xml

   ACTION: Sean to implement the above results format and codify in
   EARL if possible [recorded in
   [35]http://www.w3.org/2007/06/12-bpwg-minutes.html#action12]

   <trackbot> Created ACTION-514 - Implement the above results format
   and codify in EARL if possible [on Sean Owen - due 2007-06-19].

Summary of Action Items

   [NEW] ACTION: Dom to check how to make the names of the companies
   appear in the copyright statement [recorded in
   [36]http://www.w3.org/2007/06/12-bpwg-minutes.html#action06]
   [NEW] ACTION: Dom to give a heads up to legal team re IPR, check if
   there is anything we should carefully avoid [recorded in
   [37]http://www.w3.org/2007/06/12-bpwg-minutes.html#action02]
   [NEW] ACTION: Dom to give implementing character encoding thingy a
   shot [recorded in
   [38]http://www.w3.org/2007/06/12-bpwg-minutes.html#action11]
   [NEW] ACTION: Ignacio to annoy Miguel until he implements the change
   to java implementation to deal with reporting more than one failure
   [recorded in
   [39]http://www.w3.org/2007/06/12-bpwg-minutes.html#action08]
   [NEW] ACTION: Ignacio to check with CTIC that W3C Software license
   is legalOK [recorded in
   [40]http://www.w3.org/2007/06/12-bpwg-minutes.html#action04]
   [NEW] ACTION: Jo to check with dotMobi that W3C Software license is
   legalOK [recorded in
   [41]http://www.w3.org/2007/06/12-bpwg-minutes.html#action03]
   [NEW] ACTION: Jo to get back to BPWG on objects_or_script with
   regard to type attribute on object element [recorded in
   [42]http://www.w3.org/2007/06/12-bpwg-minutes.html#action01]
   [NEW] ACTION: Roland to check with 7Val that W3C Software license is
   legalOK [recorded in
   [43]http://www.w3.org/2007/06/12-bpwg-minutes.html#action05]
   [NEW] ACTION: Roland to research getting line and column information
   from XPath [recorded in
   [44]http://www.w3.org/2007/06/12-bpwg-minutes.html#action10]
   [NEW] ACTION: Sean research annotations in the Dom giving the source
   line and column number [recorded in
   [45]http://www.w3.org/2007/06/12-bpwg-minutes.html#action09]
   [NEW] ACTION: Sean to implement the above results format and codify
   in EARL if possible [recorded in
   [46]http://www.w3.org/2007/06/12-bpwg-minutes.html#action12]

   [End of minutes]
Received on Wednesday, 13 June 2007 14:09:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:03 GMT