- From: Abel Rionda <abel.rionda@fundacionctic.org>
- Date: Wed, 4 Feb 2009 17:51:04 +0100
- To: "Yeliz Yesilada" <yesilady@cs.man.ac.uk>, <public-mobileok-checker@w3.org>
- Cc: "Abel Rionda" <abel.rionda@fundacionctic.org>, "Kentarou Fukuda" <KENTAROU@jp.ibm.com>, "Yeliz Yesilada" <yeliz.yesilada@manchester.ac.uk>
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 16:50:55 UTC