RE: Sketch of documentation for mobileOK Basic implementation

Hi,

About markup validation I think we should use W3C validation service
especially after last announcement
(http://www.w3.org/QA/2007/03/validation_to_conformance.html). 

Another option is a Relax NG validator like
http://relaxed.sourceforge.net/ (others relax validators and related
tools at http://www.relaxng.org/). Currently there is a relax schema for
XHTML Basic at http://www.thaiopensource.com/relaxng/xhtml/ but I think
it is for version  1.0.

In TAW checker we use standard Java library (javax.imageio) for image
processing. It provides methods to get the width and height of an image,
the real format and check its transparency.

Miguel

>>-----Mensaje original-----
>>De: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
>>checker-request@w3.org] En nombre de Sean Owen
>>Enviado el: jueves, 29 de marzo de 2007 22:41
>>Para: Jo Rabin
>>CC: public-mobileok-checker@w3.org
>>Asunto: Re: Sketch of documentation for mobileOK Basic implementation
>>
>>
>>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
>>practice.
>>
>>> [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
>>on.
>>
>>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
>>practice.
>>
>>> [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
>>stuff.

Received on Friday, 30 March 2007 09:01:52 UTC