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

RE: Some feedback for moki doc

From: Jo Rabin <jrabin@mtld.mobi>
Date: Tue, 8 May 2007 11:46:03 +0100
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B42B38BA@mtldsvr01.DotMobi.local>
To: <public-mobileok-checker@w3.org>


Thanks this is great feedback. I plan to update the moki stuff soon -
but need to get the mobileOK basic LC2 document done first ...


> -----Original Message-----
> From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
> checker-request@w3.org] On Behalf Of Abel Rionda
> Sent: 08 May 2007 11:26
> To: public-mobileok-checker@w3.org
> Subject: Some feedback for moki doc
> Hi everyone,
> We have been dealing with moki document and have some comments
> -Some of the comments are inline inside the moki doc attached-
> Here is a summary:
> * We think that an explicit relationship between a request and its
> responses
>   is needed because of caching test.
> * We should avoid using boolean values (true/false) in moki doc.
>   The idea is define a value and check its correctness in a
>   way. For example, in case of encoding test, don't define an specific
>   encoding tag such as  UTF-8Validity but  something like:
>   <encoding declared="UTF-8"  inferred="UTF-8">
>   In this way, the test would do the appropriate declarative checking
> and
>   it is opened to future changes in the mandatory (or supported)
> encoding
> * We think that CSS stuff have to be discussed deeply. First of all
> ...are we
>   going to need an xml representation of CSS? This was very useful for
> scrolling,
>   but this test is now dropped, isn't it?
> * In relation with the tool JHOVE, it seems that it hasn't specific
>   modules for  validation of XHTML Basic neither CSS. Have we decided
> something
>   about this? Perhaps W3C validators tools?
>   http://hul.harvard.edu/jhove/
> * One key point that Jo mentioned in a previous mail was the stuff
>   about error codes.
>   -We think that moki has to define a uniform set of message codes
> (errors, warns...)
>    and also having a proper mapping between this codes and the
> tool ones.
>    A brief scenario:
>    *Third parties tools will have their own message codes.
>    *For each tool, we'll map these message codes (or groups of them)
>     to codes defined by us.
>    *Our codes will have a brief description (in properties files we
>     easily internationalize them).
>    *Also we can use the original tool message in moki to provide more
> description.
> Regards,
> Abel.
Received on Tuesday, 8 May 2007 10:46:23 UTC

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