The next file format

[Andreas Xavier]

---- 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 at mail.kde.org 
>https://mail.kde.org/mailman/listinfo/kde-edu 
>
>