RE: Some feedback for moki doc

Abel

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

Regards
Jo

> -----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
declarative
>   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
specific
> 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
can
>     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