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