qsos-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [QSOS-general] ideas QSOS v2 format


From: Maxence Guesdon
Subject: Re: [QSOS-general] ideas QSOS v2 format
Date: Thu, 16 Nov 2006 09:50:47 +0100

On Sun, 12 Nov 2006 19:15:57 +0100
Gonéri Le Bouder <address@hidden> wrote:

> Hi folks,
> 
> 
> Today we have (at last) two know issues with the current XML format of
> QSOS. 1) The scoring style: Today we use in general 0 for a missing
> feature and 2 for a well implemented feature. A lot of people thinks that
> ZERO means "bad" and "2" means "good".
> 2) The list: There is no easy way to store a list in a QSOS sheet.
> ...

Hello,

I have one suggestion about the format (sorry). Why not separate the
description of the tree of elements/choices and the values and comments
associated to each of these elements ?
By now, every file contains a copy of the description of elements to
evaluate, in addition to the "score" and comment for each element.

I think a better way would be to have a document containing the description
of the tree of elements with the available choices. Then, there would be a
document for each tool but this document would only contain the value
("score") and comment for each element of the description.

Then, when you edit a sheet, you would use a command like:
  myeditor description_file tool_sheet

This approach makes translation of descriptions easier since you only have
to translate the description file, and the user can use the one in the
language of his choice.

Moreover, reorganisation of descriptions is transparent for the tools
sheets, since it only stores the n-uplets (element name, value/score,
comment).

At last, the value could be a score (0,1,2, ...) but also a choice. For a
choice, I think (a, b, c, ...) is not so good. I think a string with a
little meaning is better, so that, if a choice is added to the description,
then the value in the tool sheet would still be valid. 

So, for the description, this would give something like:

<element name="books" title="books">
   <desc value="nobook">No book about the software</desc>
   <desc value="5books">Less than 5 books about the software are
available</desc>
   <desc value="more5books">More than 5 books about software are available,
in 
several languages</desc>
</element>

and in the tools sheets we would find something like:
<element name="Books" value="5books">
  <comment>bla bla</comment>
</element>

Thinking about it again, I think the score would be obtained by a separate
translation table, associating a score to value of element. This allows to
insert new scores in future versions of description documents.
For example, in a first version v1 of a description document, an element
can have three choices with scores 0,1,2, but if the tools sheets stores
the score, then, in v2 of the description, we cannot offers an intermediate
choice between 2 and 3 (if we don't use floats).

Just some ideas...

Regards,

-- 
Maxence Guesdon
http://yquem.inria.fr/~guesdon/
http://devel.inria.fr/rocq/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]