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: Wed, 04 Feb 2009 21:41:32 +0100
Message-ID: <4989FD7C.4050304@w3.org>
To: Abel Rionda <abel.rionda@fundacionctic.org>
CC: Yeliz Yesilada <yesilady@cs.man.ac.uk>, public-mobileok-checker@w3.org, Kentarou Fukuda <KENTAROU@jp.ibm.com>, Yeliz Yesilada <yeliz.yesilada@manchester.ac.uk>

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.

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/

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

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

Francois.


Abel Rionda wrote:
> Hi Yeliz,
> 
> You and your colleagues are very welcome to extend the checker. Personally, I don't see any problem as long as you are comfortable with the W3C License.
> Perhaps we should set up a new branch from the exiting trunk to address this development. Any thoughts on this from the rest of the task force members?
> 
> Best Regards,
> Abel
> 
> -----Mensaje original-----
> De: Yeliz Yesilada [mailto:yesilady@cs.man.ac.uk] 
> Enviado el: miércoles, 04 de febrero de 2009 17:19
> Para: public-mobileok-checker@w3.org
> CC: Abel Rionda; Kentarou Fukuda; Yeliz Yesilada
> Asunto: Re: mobileOK validation logic - jar file?
> 
> Hi All,
> 
> As part of my project, with my colleagues at IBM if we decide to  
> extend mobileOK library to handle local files, will we be able to  
> commit back to mobileOK library? If we can, what would be the best  
> way to work on the library?
> 
> Thanks for your help.
> 
> Regards,
> Yeliz.
> On 15 Dec 2008, at 07:11, Yeliz Yesilada wrote:
> 
>> If we use the Tester (URI) and Tester (File) in co-ordination (by  
>> testing the HTTP behaviour with Tester (URI) and the rest with  
>> Tester (File)), can we address that problem?
>>
>> I understand that checker doesn't handle local files, but why do  
>> you have a Tester(File)? so I am right in assuming that this method  
>> is not fully implemented?
>>
>> Regards,
>> Yeliz.
>> On 10 Dec 2008, at 11:10, Jo Rabin wrote:
>>
>>>> Yes, you are right. As my colleague Miguel said, the solution  
>>> for your
>>>> integration problem is to extend HTTPClient library to accept local
>>>> files. Unfortunately, we do not have much available time to work  
>>> on this
>>> I think that we also need to consider what happens to tests for  
>>> HTTP behaviour - since in this case there is no HTTP behaviour. As  
>>> mobileOK stands you must either pass or fail a test, since you  
>>> can't pass a test for HTTP behavior if no HTTP is present  
>>> presumably you must fail?
>>>
>>> Jo
>>>
>>> On 10/12/2008 08:59, Abel Rionda wrote:
>>>> Hi Yeliz,
>>>>> 1. send local HTML file to mobileOK
>>>>> 2. send a DOM object  to mobileOK
>>>>> 3. get HTML file from mobileOK
>>>>> I am not sure about the feasibility of these options. As far as  
>>>>> I can  tell from the source code and also from the documentation  
>>>>> on CVS, we  cannot do option 2 and option 3. Am I right?
>>>> Yes, you are right. As my colleague Miguel said, the solution for  
>>>> your
>>>> integration problem is to extend HTTPClient library to accept local
>>>> files. Unfortunately, we do not have much available time to work  
>>>> on this
>>>> (besides it is a bit out of scope regarding mobileOK Basic Tests).
>>>> Anyway, since checker code is open source you can extend it for this
>>>> purpose and do not hesitate in asking any doubt you might have.
>>>> Regards,
>>>> Abel.
>>>> -----Mensaje original-----
>>>> De: Yeliz Yesilada [mailto:yesilady@cs.man.ac.uk] Enviado el:  
>>>> lunes, 08 de diciembre de 2008 8:32
>>>> Para: Miguel Garcia
>>>> CC: Abel Rionda; public-mobileok-checker@w3.org; Kentarou Fukuda;  
>>>> Yeliz
>>>> Yesilada
>>>> Asunto: Re: mobileOK validation logic - jar file?
>>>> Hi Miguel,
>>>> Thanks for your quick response. Please see my comments below.
>>>> On 5 Dec 2008, at 12:45, Miguel Garcia wrote:
>>>>> You're right, Yeliz. Again there is a problem because differencies
>>>>> between Linux and Windows and how they handle uris (specifically  
>>>>> path
>>>>> separators).
>>>>>
>>>>> Solve this problem is quite easy but fixing will be reveal another
>>>>> issue.
>>>> I guess it would be good to fix this anyway as others who might  
>>>> be  interested in using this library might run into the same  
>>>> problem :)
>>>>> The checker doesn't handle local files, I mean that the
>>>>> connection library we use to handle connections doesn't support the
>>>>> file: protocol. MobileOk Basic requires the page is served by a  
>>>>> HTTP
>>>>> server in order to check some connection parameters so during  
>>>>> design
>>>>> there was no need to include a feature for analyzing local files.
>>>>>
>>>>> The connection library, HTTPClient, is extensible so it could be
>>>>> "tricked" to accept file: connections but not sure how much work  
>>>>> it  will
>>>>> take.
>>>>>
>>>>> If you tell me a bit how aDesigner and MobileOk tester are linked
>>>>> together I could think about other solutions.
>>>> aDesigner has a validation infrastructure that allows you to  
>>>> extend  it and add new validation components. Users are then  
>>>> allowed to  specify in their preferences which validation  
>>>> component they would  like to use, for example WCAG 1.0, Section  
>>>> 508, IBM Accessibility  guidelines, etc. I have extended this so  
>>>> that the users can also  choose to validate their pages against  
>>>> mobileOK. However, since we  now give the URI to mobileOK tester,  
>>>> mobileOK creates its own HTTP  connection to the target URL, and  
>>>> parses and tests the resulting  HTML. On the other hand, other  
>>>> aDesigner omponents use HTML in IE  browser. So, in some cases,  
>>>> line/column numbers (which are also used  for visualisation)  
>>>> differ because they parse different HTML  documents. Therefore,  
>>>> we need to make sure that other aDesigner  components and  
>>>> mobileOK test the same page. I talked to Kentarou  (CC'ed here)  
>>>> who is one of the main developers of aDesigner and we  think  
>>>> there are three options for this.
>>>> 1. send local HTML file to mobileOK
>>>> 2. send a DOM object  to mobileOK
>>>> 3. get HTML file from mobileOK
>>>> I am not sure about the feasibility of these options. As far as I  
>>>> can  tell from the source code and also from the documentation on  
>>>> CVS, we  cannot do option 2 and option 3. Am I right?
>>>> If you need more information, please let me know.
>>>> Regards,
>>>> Yeliz.
> 
> 
> Se certificó que el correo entrante no contiene virus.
> Comprobada por AVG - www.avg.es 
> Versión: 8.0.233 / Base de datos de virus: 270.10.16/1929 - Fecha de la versión: 02/01/09 18:02:00
> 
> 
Received on Wednesday, 4 February 2009 20:42:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 4 February 2009 20:42:17 GMT