Re: Some draft code for mobileOK Basic Tests RI

On 2/7/07, Jo Rabin <jrabin@mtld.mobi> wrote:
> Yes we are agreed on that. But in addition, we are talking about
> normalising the format of the input to the tests, i.e. creating a meta
> document.

The two big roadblocks that come to mind in creating an XML
representation of the input are:
- not-well-formed markup
- CSS

TIdy-like programs might be able to get you a DOM in some cases.
Otherwise how do you include the original doc in the input XML without
resorting to CDATA, which the XSLT can't do anything with?

I also see you're suggesting build a DOM out of the CSS styles? So
write code to parse CSS, write a DOM, then other code to later on
cascade the styles? versus using a library that has a hope of doing
all that from the source CSS?

You could try to make a DOM out of the CSS and also include the
stylesheets as CDATA, and then parse it later as needed in Java, but
then we're already to 1000+ lines of code so a few tests can be XSLT
one-liners, but not all?

I think we do disagree about how much work all this is too.

> Well I'd argue that by separating the problem into normalising the
> information input, and having a single representation of the tests
> themselves, the problem of worrying whether two different-language
> instances are the same is reduced to worrying about whether any instance
> normalises correctly.

Agree, though I think the normalizing / pre-processing stage is going
to be a large chunk of the work -- thus the "reduction" doesn't reduce
very far.

> I think the point of divergence will be whether you are an XSLT wonk or
> a Java wonk, and depending on your viewpoint you either 'simply' hack a
> bit of Java to extend, customise, produce a different version of the
> output/report, or you 'simply' hack a style-sheet.

True, I personally am no kind of XSLT expert and very much familiar
with Java. I don't think all tests will be implementable in XSLT (for
example, anything related to CSS) -- I mean non-trivially, I mean not
by doing so much preprocessing work that the XSLT implementation is
just selecting the presence of a "it worked" element of some kind.

XSLT does not seem like the obvious choice to implement these tests.
It seems that the goal is extra portability. If it's just that you
wish to extend the tests, why wouldn't it be easier are more useful to
just ensure that the test outputs are very thorough and info-rich? why
the intermediate document?

If "extensibility" means "changing the reference implementation" then
I'm not sure that's a good goal. The RI does what it does and mobileOK
Basic Tests mean what they mean, and while it's perfectly valid to add
on to that I am not sure why one would want to change what the tests
test.

I can see doing a reasonable amount of work to output an XML document
encapsulating all you know about the retrieval of the resource. If
somebody can think of a situation in which that's useful to a caller,
I'd believe it.

Then, on the assumption you can get the original document's markup
into that thing too, that it can be made well-formed, I see that
several tests are do-able in XSLT. That makes sense. I think the only
part I'm missing is why there is a need to implement all tests in
XSLT.  Sure, it would be nice; I don't think it's possible without
such acrobatics as to render the approach unuseful (e.g. how many
calls out to Java code are these stylesheets going to make before it's
done?)

> As I see it the input doc and result doc are rather similar. You can
> imagine that the output doc would optionally include parts of the input
> doc by way of an audit trail, as James says.

Again I thought James was more concerned with outputting a whole lot
of information about  what the tests did in a structured way, rather
than creating an intermediary XML document so much.

> Let's start a separate thread to fix a date for a call (talk about
> meta-activity!).

Yeah sounds like we need a call here.

Received on Wednesday, 7 February 2007 15:47:01 UTC