Re: [QSOS-general] ideas QSOS v2 format

[Maxence Guesdon]

On Thu, 16 Nov 2006 09:50:47 +0100
Maxence Guesdon <address@hidden> wrote:

> 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>

Going on in this way, I see two other advantages in the separation of
description document and tools sheets:
- extraction tools can easily use values of common elements of various tools
sheets of different "kind",
- descriptions can use external descriptions and aggregate pieces of
descriptions, to share/reuse existing description parts. Ideally, each leaf
of the description tree would be a file which could be imported anywhere in
such trees. This way, it's easier to maintain a coherent set of elements
(same names, same choices, ...), which makes the comparisons easier.

Regards,

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