[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-edu
Subject:    Re: Re: The next file format
From:       Andreas Xavier <andxav () zoho ! com>
Date:       2014-08-26 19:51:44
Message-ID: 14813dfc108.f36be73e46437.7508737106547419084 () zoho ! com
[Download RAW message or body]


---- On Tue, 26 Aug 2014 02:42:21 -0700 Inge Wallin  wrote ---- 

> On Tuesday, August 26, 2014 00:46:04 Bruno Coudoin wrote:
> > Le 24/08/2014 14:56, Inge Wallin a écrit :
> > > On Wednesday, August 20, 2014 11:23:02 Bruno Coudoin wrote:
> 
> > > Yes, confidence level is not the ideal term but so far we haven't
> > > found anything better. What it is is the level of confidence that the
> > > student has for a particular word. This tries to capture how strongly
> > > the word is put into the memory of the student, or loosely put how
> > > long it can be expected to be before they forget it. If you are not
> > > familiar with the term 'spaced repetition training', I urge you to
> > > look it up on Wikipedia, they have an excellent article about it.
> > > 
> > > This used to be known as 'grade' in Parley but we are providing a tool
> > > for learning and training, not for testing so grade is not applicable.
> > > Besides, grades also have a negative connotation in that you are a bad
> > > person if you have a bad grade. Since any low confidence level is a
> > > necessary step to the higher confidence levels we wanted to get rid of
> > > the grade connotations and that was the best we could come up with. I
> > > guess 'mark' is vaguely similar to grade in this case.
> > 
> > This is clear now and it is what I understood. Then I don't think it is
> > appropriate to put this data in the container for several reasons:
> > - may be on a read only storage
> > - may be hard to centralize the student data to let a teacher review it
> > - an update of the file would overwrite the student data.
> 
> These are very good points. Originally we didn't think about centrally stored data \
> files or files that need to be updated, nor about files on read-only media. 
> But after this round of gathering requirements we do. So our new file format will \
> support separation of student training data (statistics and confidence levels) and \
> the original word and multimedia data. This should satisfy your requirements that \
> you list above. 
> It will also support keeping them together inside the same file, like you would use \
> on a personal computer when you create your own word lists. This is a common but \
> much simpler usecase. 
> > > Would you be interested in sharing the container format with us if we
> > > can agree on how we store the internal data?
> > 
> > Sure, we have to continue the discussion and hopefully find the path
> > that will satisfy all the needs.
> 
> I think we have most requirements now. I will write a first overview suggestion and \
> put on the wiki. Since most people seem to be preferring JSON over XML I will \
> propose that.

I would like to add my voice to Todd and make a case for YAML.

YAML is more human-readable than JSON.  To a non-programmer balancing braces {} is as \
non-obvious as balancing tags.  

From reading the Dataset_handling page it looks like gcompris plans on passing the \
payload opaquely to the applications as JSON.  YAML supports embedding JSON.

The only caveat is availability of a library.  I have looked through the CMake files \
of yaml-cpp and they have options covering a range of compilers (gcc,Clang andMSVC) \
and platforms (unix, win32, and iphone).  The only required package is Boost, which \
is already required in some KDE packages.  I think yaml-cpp is probably acceptable to \
KDE but I don't know where or who to check with.
  
> Regarding the ease of use of qrc files, I am fairly certain that we will be able to \
> do a more or less in-place replacement API using the library that Andreas Xavier is \
> working on.

I have checked into qrc files.  I think we will be able to provide a url for them \
using the same mechanism that we are using for media files.  There are 2 drawbacks:  \
1. The library will not be able to verify the availability of the internal qrc \
resources because they are compiled into the application.  2. All applications that \
do not have the internal qrc compiled into them will receive a broken url, decreasing \
the usefulness of that resource to applications other than the specific one that \
saved the file. I think including qrc files in the specification is possible.  We \
should encourage applications to save the data in the zip file or using the external \
qrc format if that will be available to all of the applications using the new library \
data format.  

Cheers Andreas.

> 
> -Inge
> 
> 
> > Bruno.
> _______________________________________________ 
> kde-edu mailing list 
> kde-edu@mail.kde.org 
> https://mail.kde.org/mailman/listinfo/kde-edu 
> 
> 

_______________________________________________
kde-edu mailing list
kde-edu@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu


[prev in list] [next in list] [prev in thread] [next in thread]