mobileOK Basic Reference implementation task force teleconf

 

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

Error messages

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]

normalization/sorting of headers

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

Other issues

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 :-) ]