RE: [QSOS-general] ideas QSOS v2 format

[Pilot, Olivier]

I cannot more agree with you Maxence.
The question now is to know if we are prepared to break the libraries... But 
that's a question worth to be asked, maybe for medium-term objectives more than 
short-term ones?

O.

_______________________________
Olivier Pilot
Technical Consultant
Technology Strategy and Optimisation (TSO),
Atos Consulting
(Tel: +44 (0)7733 312 654)
mailto:address@hidden
_______________________________

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Maxence Guesdon
Sent: 16 November 2006 08:51
To: address@hidden
Subject: Re: [QSOS-general] ideas QSOS v2 format

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/


_______________________________________________
qsos-general mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/qsos-general


_______________________________________________________

This e-mail and the documents attached are confidential and intended
solely for the addressee; it may also be privileged. If you receive this
e-mail in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos Origin group
liability cannot be triggered for the message content. Although the
sender endeavours to maintain a computer virus-free network, the
sender does not warrant that this transmission is virus-free and will
not be liable for any damages resulting from any virus transmitted. 
_______________________________________________________