W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > March 2007

Re: Sketch of documentation for mobileOK Basic implementation

From: Sean Owen <srowen@google.com>
Date: Thu, 29 Mar 2007 16:40:42 -0400
Message-ID: <e920a71c0703291340y4236b0dcp427d480f050a2dc9@mail.gmail.com>
To: "Jo Rabin" <jrabin@mtld.mobi>
Cc: public-mobileok-checker@w3.org

On 3/29/07, Jo Rabin <jrabin@mtld.mobi> wrote:
> Hi Sean
> This is coming along nicely. Some comments:
> [a] afaik the jury is still out on how to actually run the tests. I
> think we should leave the architecture open and potentially run two
> parallel threads with the procedural team and the declarative team
> working in a competitive (albeit supportive, consensus driven and
> ultimately collaborative) way.

Two reference implementations? I'll be thankful if we can get one out.
I had thought the current design being discussed was about as
declarative as possible -- what more would you want to do here? at
some level there is going to be substantial procedural code and
there's no way around that.

> [b] we need to resolve what we are going to do about validity checking
> and the possible need to refer to external validity checkers

We will indeed have to make choices on libraries and run with them. I
think we have pretty good answers to all our needs in Java -- parsers
for XML and CSS, image libraries, etc.

Markup may be the most important validity check, and, I am favoring
relying on the results of parsing with an XML parser like Xerces
rather than the W3C validator library at the moment.

CSS, JPEG, GIF -- all important but I am basically content to rely on
whatever javax.imageio and the W3C CSS parser can do for us. I have a
feeling that their correctness is much more a problem in theory than

> [c] Tidy - as mentioned I prefer the idea of Tag Soup on the basis that
> it seems to hold out the promise of having a declarative statement of
> what it is trying to do, plus Ruadhan has actually used it in the
> current version of ready.mobi

Tag Soup is fine by me.

> [d] I foresee the need to allow various configuration options and thing
> there may be a need to refer to a config file to establish context
> [though I don't have a clear idea of what might be configured in such a
> file at the moment]

This is where we may still diverge -- I think mobileOK Basic means one
thing, laid out by the tests document. If it's ambiguous, it needs to
be fixed. If it's not, then it's merely a question of implementing
what it unambiguously describes correctly. I don't see the situation
where you want to explicitly support multiple possible answers about
test results. It's true that the implementation may be buggy, but the
answer to that is a bug fix. Otherwise we have "mobileOK, but with
lenient mode turned on" and "mobileOK, but using Xerces 1.2" and so

This is going to be open-source, and, anyone's free to build a
modified implementation from it or build their own from scratch, so,
there is always the possibility of divergent answers as to what is
mobileOK, some of which will be wrong. I am just pretty certain the
divergence will be negligible in practice, to the point this is not a
big problem.

Example: as you say the W3C markup validator seems to have some
glaring validation problems, but, it's still widely used and useful in

> [e] given that the intermediate results are likely to call on the
> HTTP-in-RDF  spec (which I confess I haven't had time to look at the
> latest version, having been immersed in mobileOK for the last few days)
> is it appropriate to create a schema for our document formats. Is there
> an easy way to turn an RDFS into an XSD for example?
> [f] similar ref results

Yes, um I confess I don't know much about this. I think we want a
schema for our new elements in both cases. Each document will also
include stuff from other namespaces like RDF and the HTTP-in-RDF
Received on Thursday, 29 March 2007 20:41:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:18 UTC