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

Some feedback for moki doc

From: Abel Rionda <abel.rionda@fundacionctic.org>
Date: Tue, 8 May 2007 12:25:53 +0200
Message-ID: <09700B613C4DD84FA9F2FEA521882819020CE1A0@ayalga.fundacionctic.org>
To: <public-mobileok-checker@w3.org>

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
  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
  it is opened to future changes in the mandatory (or supported)

* 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
  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
  about this? Perhaps W3C validators tools?
* 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


Received on Tuesday, 8 May 2007 10:26:56 UTC

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