mobileOK Basic Reference implementation task force homepage
See also: IRC log
Sean: various issues to be
discussed raised on the mailing list
... nothing else specific I believe
... we're all working towards the next milestone
... Roland asks a couple of questions on the list
... 1st regarding the structure of the output of the current
code vs what's on the home page
Roland: indeed
... there are discrepancies between moki and what the current
code outputs
... my question is where is the latest version of the moki
document
Sean: there is no real
documentation right now
... I expect the output and the documetn format are different
right now
... the only real ref is what is produced by the code
... we probably should only worry on actual bugs introduced by
the output document
Roland: for instance, the part
that deals with HTML is in a different node than what is
described
... will send more details to the mailing list
<Zakim> jo, you wanted to comment on this
Sean: I intend to follow Jo's format as much as possible, so that may be a mistake
Jo: one of things I intend to do
is to complete the documentation on the moki format
... but I have been delayed with mobileOK LC2 and looking at
the current code
... I'm happy to take care of keeping the doc and the code in
sync, in an iterative process
... the code I checked in this morning adds a couple of things
(e.g. doctype def)
... so it's already more compatible to what the example
shows
... a few more things needs to be looked at (e.g. utf8 validity
markup, inferred encoding)
... I also need to better understand what TagSoup is
doing
... I think that's crucial
... we already include the original document as base64
... but not really useful for debugging; would be better to
output as escaped
... as we go along, we'll probably deviate more and more from
HTTP-in-RDF, which should probably feed our conversation with
Shadi on the topic
<jo> adds that he is not a Java programmer so "caveat emptor"
Roland: I'll need to update my test moki document, based on this discussion
Sean: 2 approaches to report
error messages
... one based on Java error bundles (?)
... introduces a strong dependency on java
... but is pretty solid and easy to set up
... other option is to use XSLT to get error messages
... main concern about this is I18N
<Zakim> jo, you wanted to wonder if we can export from the java messages?
Sean: wonder if you can transparently pass the user language in that case without having the deal explicitly with the language parameter
Jo: how easy is to generate the
XSLT from the Java files?
... from dotMobi's point of view, it would be useful to be able
to rely on the XSLT without the dependency on java
Sean: main question re XSLT is I18N; does it require keeping the language parameter around?
Jo: [explains a possible solution the scribe didn't manage to capture]
<jo> [jo suggested that the language is specified as a style sheet parameter and that the error message file is accessed once in the style sheet]
Sean: that sounds like a good solution; Roland, would you be interested to prototype that change?
Roland: sure, will do
<scribe> ACTION: Roland to implement the XSLT-based solution for I18N [recorded in http://www.w3.org/2007/05/22-bpwg-minutes.html#action01]
<scribe> ACTION: Jo to update code and examples of moki to be more consistent [recorded in http://www.w3.org/2007/05/22-bpwg-minutes.html#action02]
<nacho> [we still have to try CVS, dom.. we'll do it tomorrow]
Sean: currently, for sake of
readibility, I'm sorting the HTTP headers, which Jo has a
problem with
... it helps testing too
... (e.g. to diff output)
... does it cause an actual problem?
Jo: I seem to remember that there are some corners of the HTTP spec where the order of headers is significant
<scribe> ACTION: Jo to check the HTTP spec wrt ordering and duplication of HTTP headers [recorded in http://www.w3.org/2007/05/22-bpwg-minutes.html#action03]
Sean: we're already normalizing the headers
Jo: not in all cases (e.g. values
for Date, User-Agent)
... we shouldn't do it for Location: either (since case is
significant there)
Sean: still, we're already processing quite a bit of the headers of ease of access, sorting doesn't much on top of that
Jo: sure, but may be problematic; for instance, the Host: header I think must be first
Dom: indeed, I think that's true
Sean: but still not sure whether
this affects mobileOK in any fashion
... although I understand the need to keep this a more generic
useful framework
Jo: also Vary headers may be
relevant in this case; will check further as part of my action
item
... the Vary header may influence the way we react to a 303
Multiple choices
Roland: the structure of the output document should allow for more information e.g. when the test fail, allowing to have source code fragment that triggered the error
-> http://lists.w3.org/Archives/Public/public-mobileok-checker/2007May/0077.html Roland's message on introducing source code fragment that triggered the errors
<jo> [observes that in general we need to think about the output format, it's another action I had but haven't done yet :-(]
Sean: indeed, very good point; any suggestion? That sounds tough
<scribe> ACTION: Sean to think about inclusions of code fragments in the output format and send thoughts to ml [recorded in http://www.w3.org/2007/05/22-bpwg-minutes.html#action04]
Nacho: Abel and Miguel sent this
morning their analysis of the available tools and libraries for
implementing the checker
... I would like to encourage everyone to read it, and take
part to it through google docs
<jo> what is the URI?
Nacho: (just send me your gmail account if you want to participate)
<nacho> http://docs.google.com/Doc?id=dhbw7zt7_0f8w6bq
<jo> tx
Dom: I think we should go through it during our next call; lots of useful information and discussion in it
<jo> [it's a great resource, Nacho et al!]
<nacho> [thanks, sir :-) ]