Re: Limitations of the current checker

Hey Dom and Everyone

Agree that this work is now more than a little out of date and the bits that are most out of date cast a shadow over the bits that are not.

A couple of brief thoughts:

a. The checker implements mobileOK Basic Tests [1] - updating the checker presumably implies updating that document - or does it? The authority for the checker in part derives from the status of mobileOK Tests as a W3C Rec. So where would the authority for an updated checker come from if mobileOK Tests was deprecated? Indeed, never mind the authority, a fair amount of debate and consideration (ahem) went into wording and refining that doc, I'd imagine that at least the same if not more debate would be needed for a new one. The alternative of not producing an updated Rec seems quite tricky really.

b. You mention that you think a "real" browser would be needed. I'm increasingly thinking that it would be quite useful to have a canonical headless browser but am worried that that would no doubt be a journey into a very deep swamp. The size of a large continent, I expect.

c. I remain in favour of an intermediate representation - currently MOKI but lessons no doubt need to be learned on that - not least to preserve at least theoretical open-endedness in application of some of the resulting software.

d. A Checker is not just for Christmas. Emphasize the need for thinking about the ongoing maintenance that ought to accompany a revised initiative.

Best
Jo

[1] http://www.w3.org/TR/mobileOK-basic10-tests/

T: @jorabin
S: jorabin
M: +44 7904 185 975
O: +44 20 3603 7114

On 26 Mar 2012, at 14:03, Dominique Hazael-Massieux wrote:

> So, why do I want a new checker?
> 
> The current checker verifies tests that were derived from the Mobile Web
> Best Practices which for all intent and purposes where finished in July
> 2007, that is before the arrival of the 1st iPhone, which I think is
> fair to say changed completely the way people have been using and
> developing for the Mobile Web.
> 
> While the Best Practices themselves are for the most part still
> relevant, their derivation in mobileOK are based on the so called
> "default delivery context", an abstract mobile browser that is years
> behind what current browsers do (no support for PNG, JavaScript, Media
> Queries, etc).
> 
> So, the output of the current checker has some useful parts, but most of
> them are drowned under the noise created by the outdated ones.
> 
> In terms of the software base, the overall architecture of the tool is
> not necessarily bad (if not very efficient):
> * the code is split between a library and a front-end (both in Java)
> * the library does it checks with separate layers for:
> - retrieving resources, parsing them (recursively as needed)
> - deriving facts about the retrieved resources (size, validity, http
> status, etc) into an XML structure (called moki)
> - analyzing these facts (via XSLT style sheets) into a final XML
> structure that reports the mobileOK analysis of the checked document
> 
> We know that the library has been re-used in a number of other projects;
> I'm not clear whether the integration is done at the Java level, or via
> the produced XML output. I don't know (yet?) if that re-use is
> sufficient to justify ensuring some form of compatibility or not.
> 
> One of its big weaknesses that would have to be fixed is the way it
> parses resources: because of the "default delivery context" assumption,
> it behaves as a very dumb-down browser (e.g. only downloading
> type='handset' stylesheets, or downloading all background images quoted
> in a stylesheet no matter whether it is actually downloaded by a real
> browser, not downloading scripts, etc). As I'll develop in a separate
> message, I think the only good way to fix this is to use an actual Web
> browser to do the parsing/retrieving.
> 
> Dom
> 
> 
>