libkeduvocdocument name

Inge Wallin inge at
Wed Aug 13 16:46:25 UTC 2014

On Wednesday, August 13, 2014 06:37:59 Andreas Xavier wrote:
> Hello,
> If we are going to abandon the library for a new library with the new format
> , then I think we should stop work on libkdeedudocument now and not read
> any further in this email.

Nobody is talking about abandoning it.  At least I don't think so. If nothing else, 
libkecuvocdocument is needed for backward compatibility with lots of existing files in 
applications like Parley, hangman, etc. What the thread is about is if we want to rename 
this library to something else - which I don't think (see below).

> I think that we should keep the library and iterate toward a new api and the
> new file format, maintaining functionality for artikulate, kanagram and
> parley as we proceed.

I don't think that, for two reasons:

1. The old file format and the old API of the library should not change. At the very most 
they can be expanded with some new fields or new calls. But we need to maintain 
backward compatibility with old applications - including non-kde apps that we don't even 
know exist.

2. The new file format will introduce so many changes that it will not be possible to evolve 
the library while still maintaining backward compatibility. We need a new library in addition 
to the old one. Note: not instead of but in addition to.

> I think that the name of the library should be meaningful even if only used
> in conversations about the library.  In libkdeeduvocdocument, the kdeedu
> portion is just preamble and the document portion is misleading, because it
> is more a collection of vocabulary related sets and things.

Actually it's keduvoc..., not kdeeduvoc... :). Yeah, I was confused by that too in the 

> As a name I like libLexikon. It is meaningful, with fun short forms liblexi
> and lexi.
> If we keep this library, then I think that the next 2 steps are:
> 1. Split the kvtml2 writer away from the core object and set it up with
> unittests and a writerManager in the same way as the readerManager.
> This supports future multiple output formats and will speed up development.
> 2. Write unittests around the individual chunks of KEduVocDocument and make
> it into a QObject with everything a property, signal, slot or overloaded
> function for maximum future source and binary compatibility.
> Give me a sign and I can start this work or not.

The new format is not designed yet.  But I think that we agree on a few key points (correct 
me if I am wrong here):

1. It should be based on a ZIP store. This is well handled by the KArchive framework in KF5, 
although I think the API is overly complex.

2. We want to separate the word/data content from the confidence levels ("grade" in the 
old terminology). 

3. The data format should be based on XML, similarly to kvtml files.

My suggestion would be to call the two parts words.xml and training.xml. There may be 
more parts, e.g. pictures and sounds (and other multimedia too, like videos?). The Open 
Document Format, ODF,  uses internal links to access those and normally they are kept in 
subdirectories like Pictures/ and Sounds/ inside the ZIP store.

If you want to start, I think you can start a new repo and start to write code and tests for 
these basic properties, I am all for it.

Other things that we might like to copy from ODF is a /mimetype file with the mimetype of 
the format and a nice manifest.

Somebody suggested that we base the format on the Open Packaging Conventions, OPC, 
which is the base for many file formats, especially on windows. It's more complex than ODF 
but also slightly more expressive and flexible. 


> Andreas
> ---- On Mon, 11 Aug 2014 11:56:39 -0700 Inge Wallin  wrote ----
> > Hi guys,
> > 
> > Sorry to be a bit late to the table, but here is my input anyway...
> > 
> > On Wednesday, July 30, 2014 14:41:12 Jeremy Whiting wrote:
> > > Peter,
> > > 
> > > You make a good point. Actually the name being old isn't the only
> > > reason to change it. There are two reasons. One is that
> > > libkeduvocdocument is quite a mouthful. But the more important one is
> > > that in the future we plan to update the library to use a new file
> > > format.
> > 
> > Well, this is not completely accurate, at least not if I only go the plans
> > that are still only in my head and not written down.
> > 
> > It's true that we want to create the new file format but I am not sure
> > that putting the code in the old library is the way to go. Perhaps we
> > will create a new library that uses keduvocdocument or perhaps we will
> > introduce incompatibilities that make the new file format not use pure
> > keduvocdocument.
> > 
> > Parley, the application, will of course still support the old formats, so
> > no change there.
> > 
> > In short, do not support the name change of the repository. I think we
> > should keep keduvocdocument for the old format and (maybe) lexikon for
> > the new format.> 
> >  -Inge
> >  
> > > The technical details haven't been ironed out completely yet,
> > > but ideally we want the xml and any accompanying image and sound files
> > > to be included within one compressed file (most likely zip) for
> > > simpler uploading, downloading, and sharing of vocabulary files. A bit
> > > of work has been done looking at existing file formats and standards,
> > > but nothing has been set in stone yet (or in code either) and I'd like
> > > the change to be gradual rather than all at once if we can. However
> > > since libkeduvocdocument has it's own git repository now I'd like to
> > > have a name for the git repository and the library to begin with, it
> > > will be much harder to rename the git repository or library after we
> > > have a few releases with the long libkeduvocdocument name.
> > > 
> > > BR,
> > > Jeremy
> > > 
> > > On Wed, Jul 30, 2014 at 2:34 PM, Peter Hedlund <peter at> wrote:
> > > > Hello,
> > > > 
> > > > Not that I am going to argue one way or other since I am not very
> > > > involved
> > > > these days, but it seems that if the only reason for a change is that
> > > > the
> > > > name is old then I don’t see the point. It appears your real issue is
> > > > with the kvtml extension but changing that would confuse existing
> > > > users.
> > > > 
> > > > Thanks,
> > > > Peter
> > > > 
> > > > On Jul 30, 2014, at 1:13 PM, Jeremy Whiting <jpwhiting at> wrote:
> > > >> Hey all,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the kde-edu mailing list