Requirements for mobileOK reference checker


I'm afraid I have not had as much time to work on this as I had hoped,
but anyway, I've attached some initial thoughts.

By way of introduction, the document could be about "How the project
will operate." "What the checker does." "How it will do it." In fact the
document takes in these topics and a few more too.

Thoughts gratefully received.


Outline requirements for mobileOK Basic 1.0 Reference Checker [Version

1. Licensing

[1.1] The output of the group's work is to be open source and is to be
freely licensed under the terms of [OQ] license.

Elaboration: we need to allow considerable flexibility here - people
should be able to take the output of the work and use it in pretty much
any way they like, including making changes and not contributing them
back. Noting that at present the work is not under any W3C charter,
contributors need to be free to contribute under their employers
contribution policies etc.

[1.2] It is likely that the Reference Checker will include components,
or use services whose use if governed by license agreements of some
kind. Those license agreements MUST be compatible with that in [1].

2. Conformance

[2.1] The output of the reference checker MUST state which version of
mobileOK is being checked against and MUST state its own version number.

The checker assesses conformance with a number of standards and
recommendations other than mobileOK (external standards).

[2.2] Where possible the checker SHOULD NOT create independent
implementations of external standards conformance checkers and should
use accredited, where possible, or de facto standard implementations.
[We do need to work out how to meaningfully check for validity of UTF-8,
JPG, GIF and CSS etc.]

[2.3] In order to minimise possible version drift between the checker
and external validators on which it depends, it MUST include an option
to use those services remotely (e.g.

[in the above, I think there is a tension between wanting to give
consistent results (not being dependent on external vagaries) and
needing to be consistent with the authoritative checker]

3. Deployment/Use Cases

It is the intention that the checker will be a component of the
following deployments:

[3.1] As a component of a public service where users type a URI for
checking into a user interface

[3.2] As a component of a public service which offers a programmatic
interface for use remotely by other programs

[3.3] As a component of a program running on the same computer

[3.4] As part of an IDE

[3.5] ...

4. Structure

[4.1] The checker will have a manifest architecture that is documented
separately from its code

[4.2] Input to the checker will be specified by URI [should we consider
a literal string as well? given that the checker needs to check most
external references, would this in fact be useful? Yes, if the tests
relating to external references are skipped, or if the base uri can be

[4.2.1] Other inputs to include varying the request headers and request
partial execution of the tests.

[4.3] The checker will be written in Java and provide a programmatic
interface with bindings initially to Java [and SOAP?]. [Are we going to
write something other than Javadoc by way of documentation/design?]

[4.4] The checker development project will not develop a user interface
except as necessary for testing it, but the use case of its deployment
in a human request / response environment should be borne in mind.
Specifically this should not be seen as a project to create the W3C
mobileOK checker.

[4.5] The checker will create an intermediate document that makes
available for inspection all details of retrievals, validation and other
pre-processing required in order to carry out the tests. The format of
this intermediate document will be specified separately, and will use
existing representations [like RDF/HTTP] where possible.
[and per resolution of 26 Feb from an API perspective this needs also to
be available as DOM or SAX-wise or as a Java class?]

[4.5.1] To take account of the possibility of input documents that are
not well-formed or that may be invalid (or may just be binary), the
checker will embed them in the intermediate document in a form that
preserves the integrity of the input document while making it possible
to reconstruct the original document [including character encoding, for
text documents][if this is done RDF/HTTP wise then it says to include as
BASE64 encoded]

[4.5.2] To allow processing of mal-formed and invalid primary input
documents (those that are the subject of the test, rather than resources
that are referenced) the pre-processing will provide a 'cleaned up'
version [whose xml header and Doctype declaration at least, will need to
have some magic performed to allow inclusion in the middle of the
document] and that the nature of the clean-up needs to be explicit and
not implementation dependent [i.e. using Tidy is all very well, but it
is opaque in its operation; from this pov, perhaps we should look more
closely at Dom's suggestion of
which (I think) operates on the basis of explicit rules which can be
captured and repeated]

[4.5.3] The intermediate document is to be suitable for audit purposes
and MUST contain sufficient information to justify test results.

[4.5.4] It will contain the external resources required to complete the
tests together with their retrieval information and validity

[4.5.5] HTTP parameters and their values should be recorded in a
normalised form as well as being recorded in their original form.

[4.6] The checker will produce a test report document describing the
results of carrying out the tests together with appropriate WARNs and
other diagnostic information. The format of the result document will be
specified separately and will use appropriate existing representations
[like EARL].

[and per resolution of 26 Feb from an API perspective this needs also to
be available as DOM or SAX-wise or as a Java class?]
[4.6.1] There MAY be limited or truncated versions of the report

[4.6.2] It must be possible to request the inclusion of the intermediate
document as part of the report

[4.7] It must be possible to add tests without recompiling the checker.

[4.8] It must be possible to replace sub-components (such as remote
validation steps) by configuration option.

5. Process

[5.1] The project will create documentation explaining the trade-offs
between performance, flexibility and maintainability in making those
choices. [this is a proxy for saying it will be cheap, fast, good,
flexible, maintainable ...]

[5.2] Source code and documentation for the project will be kept at the
W3C CVS repository [ref]

Jo Rabin
mTLD (

Received on Wednesday, 7 March 2007 13:44:11 UTC