- From: James G Pearce <jpearce@mtld.mobi>
- Date: Mon, 5 Feb 2007 09:57:56 -0500
- To: "Sean Owen" <srowen@google.com>, <public-mobileok-checker@w3.org>
- Message-ID: <815E07C915F39742A29E5587B3A7FA192863DA1C@lk0-cs0.int.link2exchange.com>
Hi Sean, Nice framework! Thanks. One idea we had was to try to aim to describe as many of the tests as possible in a language-agnostic way. The test descriptions could be picked up at run time. This would have a number of advantages: * Easier porting of the engine (it's just a test interpreter) * Decoupling the implementation from any changes made to the tests themselves * Makes it easy for 3rd parties to add additional tests (at least those which can be described in that way). As for the way to describe the tests, there are probably plenty of common approaches. But it basically would need to be a query that is applied to a possibly-XML document (and its headers, and its dependencies) and which returns a tri-state: passed/failed/not-run. One approach I've used in the past for this sort of thing is Xpath (The "Page must not contain frames" test is codified as ".//frameset returns 0 nodes"), but we'd need to pre-process the document against which the Xpath is run to make sure it a) was coaxed into being well-formed, b) contained meta-data like HTTP headers and binary object sizes etc, as required to evaluate the tests. e.g. // ns1 = fetched HTML // ns2 = pre-processed additions <ns2:document> <request method='get'> <header name='...' value='...' /> <header name='...' value='...' /> <body /> </request> <response status='200''> <header name='...' value='...' /> <header name='...' value='...' /> <body size='4523' totalsize='23325' xmlvalid='true' xmlwellformed='true'> <ns1:html> <head>...</head> <body> <p> <img src='aa.gif' ns2:status='200' ns2:size='1575' ns2:content-type='image/jpg' ns2:width='200px' ns2:height='150px' ns2:depth='256' /> </p> <p> <a href='other.html' ns2:status='200' ns2:size='18234' ns2:content-type='text/html' /> </p> </body> </ns1:html> </body> </response> </ns2:document> A nice side-effect of this sort of meta-document is that you could start attaching the test results to the top too, and then it goes on to double up as the output of the checker as a whole, complete with audit trail. There are probably other ways this could be done. SAX, regex, or simply parameters to a smaller set of test classes, for example. Or all of the above... But it's the approach itself I'm most interested in socialising at the moment. Any thoughts? Regards, James James Pearce CTO http://mtld.mobi <http://mtld.mobi/> -----Original Message----- From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-checker-request@w3.org] On Behalf Of Sean Owen Sent: 05 February 2007 14:31 To: public-mobileok-checker@w3.org Subject: Re: Some draft code for mobileOK Basic Tests RI That attachment was too big -- here is just the source code which is much smaller. To actually compile it, if you want to do that, you need Jakarta Commons HttpClient, Codec and Logging classes. Sean On 2/5/07, Sean Owen <srowen@google.com> wrote: > (Does this list accept attachments -- and/or is it generally a bad > idea to send big attachments to these lists?) > > Here's a sketch of the mobileOK Basic Test framework plus a partial > implementation of the caching test. It's enough to demonstrate what > I'm thinking and start an API discussion. Before I do anything more or > deal with dev.w3.org we should finalize the structure of the API. > > Sean > >
Received on Monday, 5 February 2007 14:58:12 UTC