libkeduvocdocument name

[Inge Wallin]

On Wednesday, August 13, 2014 10:44:13 Andreas Xavier wrote:
> Inge,
> Thanks for the answers.
> 
> Two things:
> 
> 1. What do you want the library named?

liblexikon is what we discussed on irc.  Any objections, anybody?

> 2. I read the OPC spec and in the foreword there is the following sentence
> about patent rights.
> 
>   "Attention is drawn to the possibility that some of the elements of this
> document may be the subject of patent rights. ISO and IEC shall not be held
> responsible for identifying any or all such patent rights."
> 
> Is this a problem?

I don't think so. Calligra has been implementing OPC features for years with no problems.  
And we are not selling anything so we cannot be sued for damages. The only thing might 
be that we have to stop using it which is very unlikely, considering that MS wants people to 
use OPC.

	-Inge



> Andreas
> 
> 
> ---- On Wed, 13 Aug 2014 09:46:25 -0700 Inge Wallin<inge at lysator.liu.se>
> wrote ----
>  >  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 beginning. >  
>  >  > 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. >  
>  >   -Inge
>  >   
>  >  > Andreas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20140814/842666ca/attachment-0001.html>