- From: Yeliz Yesilada <yesilady@cs.man.ac.uk>
- Date: Mon, 15 Dec 2008 07:11:30 +0000
- To: public-mobileok-checker@w3.org
- Cc: Abel Rionda <abel.rionda@fundacionctic.org>, Miguel Garcia <miguel.garcia@fundacionctic.org>, Kentarou Fukuda <KENTAROU@jp.ibm.com>, Yeliz Yesilada <yeliz.yesilada@manchester.ac.uk>, Jo Rabin <jrabin@mtld.mobi>
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.
Received on Monday, 15 December 2008 07:12:24 UTC