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