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:26:56 UTC