RE: Requirements for mobileOK reference checker

> -----Original Message-----
> From: Ignacio Marin [mailto:ignacio.marin@fundacionctic.org]
> Sent: 11 March 2007 20:13
> To: Jo Rabin; public-mobileok-checker@w3.org
> Subject: RE: Requirements for mobileOK reference checker
> 
> Hello, Jo and everyone else:
> 
> First of all, I want to say that these outline requirements sound great to
> me. Thanks for such a good job, Jo.

That's kind of you!

> 
> Some things come to my mind after reading them so here I go:
> 
> - We might set as a requirement to clearly note all the decisions taken
> into the implementation that we are going to build which are
> "implementation decisions" so the public can know it was something that we
> decided at the very time we wanted to give a solution to a problem we
> found (that is, "implementation decisions" we took and are not part of
> MobileOK 1.0 Basic Tests document.

Agree strongly. Think that this should take the form of a design document that gets updated as we go along?

> 
> - About [4.5.2], Dom suggested .... and Miguel talked about another tool
> (he mentioned it in his first email to this list but he did not send an
> URL... Jericho HTML Parser [1] maybe?) I do not know about these tools,
> but maybe with the help of Dom and Miguel we can find which one is the
> best for us.
> 
> - I do believe we should create a good documentation (I do not know if
> following any software engineering methodology or something more
> informal). I volunteer to edit that doc or to collaborate working on it.
> 

Sounds like an offer that one could not refuse!

> Last but not least, doesn't the teleconference overlap with DDWG's one?
> 
> Regards,
> 
> Nacho
> 
> [1] Jericho HTML Parser
> (http://jerichohtml.sourceforge.net/doc/index.html)
> 
> 
> 
> -----Mensaje original-----
> De: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
> checker-request@w3.org] En nombre de Jo Rabin
> Enviado el: miércoles, 07 de marzo de 2007 14:44
> Para: public-mobileok-checker@w3.org
> Asunto: Requirements for mobileOK reference checker
> 
> 
> Hi
> 
> 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.
> 
> Jo
> 
> 
> Outline requirements for mobileOK Basic 1.0 Reference Checker [Version
> 0.1]
> 
> 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. validator.w3.org).
> 
> [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
> supplied]
> 
> [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 http://home.ccil.org/~cowan/XML/tagsoup/
> 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
> information.
> 
> [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 (http://dotmobi.mobi)

Received on Wednesday, 14 March 2007 13:10:06 UTC