Re: Requirements for mobileOK reference checker

On 3/12/07, Jo Rabin <jrabin@mtld.mobi> wrote:
> I think the key point is that it would be nice to offer a 'tools'
> interface. i.e. try to encourage people to submit stuff _before_
> committing to their server. I know there are other ways of doing this
> and I know that this will be far from complete but nonetheless think it
> could be useful.

Sounds good. Yes it may mean only some tests can be run this way.

> I wonder how much of an obstacle to porting the 'the code is the
> documentation' approach presents?

My take is that some of the API is not platform-specific, like the
output format. The implementation itself and the Java API are
Java-specific and so might as well be documented with the
Java-specific tool. There will definitely be a need for some kind of
document outside of the javadoc, yes.

> Well, that is up to Dom / W3C isn't it?

Sure, separate issue.

> We need to decide what the primary representation is, I think. I'd
> prefer this to be documented as a Schema and have a mapping from the
> schema to Java native class rather than vice versa.

I think it's six of one and half a dozen of the other -- an
implementation detail as to which is based on which. If the point is
that both representations should represent the same information in the
same structure then I agree.


> Yes, this is really to answer the point in mobileOK about giving maximum
> possible info to developer. i.e. to try to prevent them fixing problem
> 1, rechecking, fixing problem 2, rechecking and so on. It will be
> imperfect whatever we do, of course.

I agree. I suppose I'd like to introduce this functionality as an
explicit option -- lenient or strict mode with a default to strict? --
to avoid confusion about what the outcome really is.


> Sorry, I did not mean parameters. I meant headers, as you correctly
> inferred. My point is that it makes post-processing easier if you always
> report Content-Type as that and not as content-type if that is what the
> server actually returned.
>
> Equally, if we are to use HTTP-in-RDF then we'd want to know what had
> been transformed in order to arrive at the processed RDF representation.

Ah OK. I agree. One should know about the before-and-after form for
normalizations that may have a non-trivial effect. One way is include
both the complete original body and headers in the output in some way.

If the only info we're losing is case in header names (and they aren't
case sensitive, right?) then maybe including the original HTTP headers
is unnecessary. Maybe there are other possible normalizations I'm not
aware of.


> > Yes, well I thought the idea is that the implementation should
> > externalize enough information that external entities can reuse that
> > information to write more tests. I don't imagine one would extend the
> > implementation by actually modifying it.
> >
> Well that would be one way of meeting the requirement :-)

Requirement met then, check.

> > What does this mean, just that there needs to be some configurable
> > behavior? I agree though want to be careful that a PASS means
> > something clear -- not "PASS, but if you set this option" but
> > deifnitely "PASS"
>
> PASS is always conditional on the processing you have done. If you use
> 'ropey-old-validator-that-barfs-on-the-wrong-stuff' then you have a
> different meaning of PASS than if you use
> 'industry-standard-and-most-up-to-date-validator'. So I think this is
> why the validation steps need to be named, reported on and open to
> configuration.

I'm still not convinced on this one --

True, and this is why this implementation and all it depends on are
hopefully bug-free. If an implementation has a bug vis-a-vis the spec,
it needs to be fixed. Fixing it by letting someone swap it out on
their own is less than ideal.

If two implementations differ but neither is clearly wrong, one
consults the reference implementation if it's important. So I think
that using the reference parser is a good place to start -- the W3C
one? but again letting you pick your reference implementation parser
is letting you mix your own reference implementation of mobileOK, and
I feel it's important to have One Clear Reference Implementation.
Otherwise you have "mobileOK-based-on-Xerces" and
"mobileOK-based-on-W3C-parser" and permutations thereof.

Received on Tuesday, 13 March 2007 04:30:05 UTC