W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > February 2009

Re: mobileOK validation logic - jar file?

From: Francois Daoust <fd@w3.org>
Date: Fri, 06 Feb 2009 13:58:17 +0100
Message-ID: <498C33E9.4020105@w3.org>
To: Yeliz Yesilada <yesilady@cs.man.ac.uk>
CC: public-mobileok-checker@w3.org, Kentarou Fukuda <KENTAROU@jp.ibm.com>, Yeliz Yesilada <yeliz.yesilada@manchester.ac.uk>

Yeliz Yesilada wrote:
>> I need to check how you could get write access to the CVS project. 
>> I'll get back to you as soon as I know.
> OK, thanks.

In short, I'll just need the names of the persons who need an account. 
If some of these persons already have a W3C member account, let me know 
as well. Send me a private message when you need the access. Account 
creation may take 7-10 days, depending on the availability of the 
systems team.

> We are trying to get familiar with the code, I am sure we will have 
> questions and subjects to discuss with the group, so we will become a 
> member of the list.

If you feel some questions could better be answered in a call, I'd be 
happy to schedule it.


>> I personally think the feature is useful, in particular because 
>> authors usually start to write a page locally before they publish it 
>> on the Web, and could then start checking the page at this stage.
>> However, as noted previously, some (and actually that's not only one 
>> or two) tests only apply to content delivered over HTTP. Other may 
>> apply only partially to non-HTTP content (PAGE_SIZE_LIMIT and 
>> EXTERNAL_RESOURCES for instance would not be able to count the size 
>> and number of potential HTTP redirects since there's no HTTP redirects 
>> in the file scheme).
> I agree, for a complete test, one needs to use the URI version.
>> IMO, that means:
>>  1. that the Checker must never return a "you are mobileOK" message 
>> when run on a file. It would not be true. The message can be at best 
>> "all the mobileOK tests I could run on the file passed".
>>  2. we need to be able to identify this situation in the moki schema.
>>  3. we need to be able to identify subtests that cannot be run in part 
>> or completely in this situation e.g. by adding a new attribute to 
>> <result> elements such as run="[impossible,partial,complete]".
> Thanks for these suggestions. It seems like it will be good to first 
> categorise/group the tests based on these three attributes.
> Regards,
> Yeliz.
Received on Friday, 6 February 2009 12:58:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:20 UTC