RE: Some draft code for mobileOK Basic Tests RI

Yes. At some point, you're going to have to do a lot of logic. Either before or during test application.

dotMobi very publically intends to extend the test suite (e.g. see http://ready.mobi). So I've naturally come down on a flexible implementation model that accelerates (or even deskills) additional test deployment :-) 

The language porting requirement is not a big deal for us (we're happy with Java), but that's a nice side effect.


If one was mean enough to annul all subsequent testing once a doc was found to be non-wellformed, then you'd not need to worry about tidy-ing, tag-soup-ing, SAXing, regexing etc. And a single descriptor language (XPATH, within or without XSLT) would give fairly broad coverage. Very elegant & extensible.

But if you want to have a bash regardless (and let's be honest, browsers do) then relying on wellformed-assuming technologies needs a lot of supporting logic. And then the question is "why use the XML meta-doc approach at all?"


One important answer: we can use the meta-doc as rich (although possibly optional) output from the tool anyway. It could be encompassing enough to contain the MobileOK test results themselves, or it could simply be a secondary 'debug' output that can be used as an audit trail. 'Why did you you fail me on that page last week? Oh, you're right, my headers really were f*cked up'.

Short of a TCP packet trace, a meta-doc would really be the best way to encapsulate the HTTP conversation that was under test. Even if you hadn't actually used the meta-doc as the test subject.

So then you can flip the question round. If you're building a meta-doc for audit purposes anyway, why *wouldn't* you use it as the test subject?


Conclusion: I think either approach can be well argued at the test-execution stage. But the additional benefits of capturing your subject in one document anyway are fairly significant.


Nevertheless, we need to get together in an Dublin pub to discuss this tricky issue. Who's in?

James




-----Original Message-----
From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-checker-request@w3.org] On Behalf Of Sean Owen
Sent: 06 February 2007 19:12
To: Roland Gülle
Cc: public-mobileok-checker@w3.org
Subject: Re: Some draft code for mobileOK Basic Tests RI

On 2/6/07, Roland Gülle <roland@7val.com> wrote:
>
> > In this case I think James's idea ref XPath would work, perhaps in 
> > the context of an XSLT.
> >
> > So I guess a question is: could one define the mobileOK reference 
> > implementation as an XSLT, given sufficiently strict definition of 
> > the preceding steps?
> In my opinion: yes.
>
> Transforming structured data with an XSLT (instead of validating 
> against a schema) is a great choice to generating a context sensitive 
> feedback.

The proposal here is to produce an intermediate XML representation of the test state -- the document, headers, CSS, image formats and any errors encountered, parsing errors, encoding problems. From there, I bet you could XSLT-transform this into test results. The goal is easy portability, since XSLT and XML are quite cross-platform.

But the hard part, the heavy lifting is of course producing that intermediate doc. Implementing code that produces this intermediate representation seems like it can't be done in a language-neutral way.
There are some details here like wrestling with encoding and image formats and CSS that can't be described by a transform.

Given that, I don't yet see the value in the additional code and performance overhead needed to generate the intermediate document. It may save a little bit of additional code, but, it's the code for the easy part, like running some XPath queries.

I could sure be convinced, that's just my take at the moment. I may have misunderstood the proposal.


> The feedback (of course, XML) could be interpreted with your preferred 
> program language (or with another XSLT to generate a HTML output).

I think it definitely makes sense to make results available as an XML document.

> If I could help with a prototype, let me know.

I think any kind of prototype is great at this point as we knock around ideas. Prototyping the bit that produces this intermediate XML document seems like the most crucial next step for that approach. We probably want to define an XML format for the test results too.

Received on Tuesday, 6 February 2007 20:39:07 UTC