Re: mobileOK validation logic - jar file?

Hi Francois,

On 4 Feb 2009, at 20:41, Francois Daoust wrote:

> Yes. Come and join the list!

:)

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

> I do not think a branch is really needed for the time being. There  
> is no active development on the mobileOK Checker right now apart  
> from bug fixing. The branch could be created afterwards if needed  
> (I tagged the library as v1-0-03 today, so we'd have an easy way to  
> rollback or branch if that's truly needed). I guess it also depends  
> on the expected timeline.
>
> I would suggest you use this mailing-list as well to discuss  
> implementations details if that's OK with you, so that other  
> involved in the Checker can chime in and/or help if interested. You  
> can subscribe to the list through the "subscribe to the list" link in:
>  http://lists.w3.org/Archives/Public/public-mobileok-checker/

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.

>
> 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 08:52:51 UTC