- From: Sean Owen <srowen@google.com>
- Date: Wed, 7 Feb 2007 10:46:40 -0500
- To: "Jo Rabin" <jrabin@mtld.mobi>
- Cc: public-mobileok-checker@w3.org
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