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

List:       kde-edu-devel
Subject:    [kde-edu]: kvtml
From:       Frederik Gladhorn <frederik.gladhorn () gmx ! de>
Date:       2007-06-06 13:45:53
Message-ID: 200706061545.58193.frederik.gladhorn () gmx ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

[Attachment #4 (multipart/mixed)]


Hi all!
Hi especially Jeremy :)

As we all seem to agree about kvtml being somewhat awkward, it's time to redo 
it. Since Jeremy offered his help and interest, I'll try to sum up some 
concerns and also attach an example doc, the latest version of kvtml which 
Peter Hedlund and I pretty much worked out. XML experts, join us ;) also a 
real dtd would be great.

Since many of the features are not yet supported by libkdeedu, that has to be 
changed significantly. It's no small task.
I already played around with it, but I do not have the time nor the knowledge 
to rewrite it quickly. (E.g. I did not know about the d-pointer concept to 
keep ABI compatiblity etc...)

I'll still be glad to work on it, but not alone, form now on. *big grin*

So this is a summary of problems and concerns that came up before.
Some of the stuff only concerns KVocTrain, but all apps using the lib will 
gain something from cleaner lib code.

Quote Peter (different e-mails):
> One major issue with the current kvtml format (IMHO) is that it's bad xml.
> It relies very heavily on attributes where child elements would be better
> for parsing and readability
> (http://www.w3schools.com/xml/xml_attributes.asp). Elements and attributes
> should also have proper tag names, not just a single letter. All elements
> should probably also have unique tags regardless of parent element for more
> efficient parsing (Now e.g. <e> is used with several different parents and
> different meanings.
>
> For future expansion I would also like to add the tags <image> and <sound>
> to vocabulary entries. They should both take an URL for an image or sound
> file.


> I would like to add a <sizehint> tag   as a child to <entry> for storing row
> heights. I know KVocTrain has always used fixed row heights, but I would
> like more flexibility at least for KWordQuiz. See
> http://bugs.kde.org/show_bug.cgi?id=82460.

> > So we simply call it kvtml2 ? Other suggestions? I guess we might as
> > well. That is easier than I thought. I don't care for writing the old
> > docs. It is enough work supporting reading, but not that bad either.
>
> I think we can keep the file extension. I was talking about the source
> files in svn. I think the code should send a kvtml file to the new reader
> first. If the version="2" attribute is not found, the new reader returns an
> appropriate error and the file gets sent to the old reader.

Quoting myself:
> The concept of original language + x translations is not really great for
> apps that actually can have more than two languages. So far it is never
> possible to practice language 2 with language 3.
> This is intersting for people learing eg. Chinese or Japanese, to have some
> sort of signs and maybe traditional and simplified and be able to practice
> them in respect to each other.
> See bug #93446 (https://bugs.kde.org/show_bug.cgi?id=93446).
>
> Another thing is that this concept blows up the code unnecessarily and in a
> ugly way. Because everywhere there is special treatment for original, than
> an iteration over all translations.
> KVocTrain and also the lib we have about thousand places like (rather small
> example of duplicate code directly next to each other):
>
> (from keduvocdocument.cpp)
> if (sort_column == 0)
>             return e1.original().toLower() < e2.original().toLower();
>          else
>             return e1.translation(sort_column).toLower() <
> e2.translation(sort_column).toLower();
>
> This will become:
> return e1.translation(sort_column).toLower() <
> e2.translation(sort_column).toLower();

> The concept of original language + x translations is not really great for
> apps that actually can have more than two languages. So far it is never
> possible to practice language 2 with language 3.
> This is intersting for people learing eg. Chinese or Japanese, to have some
> sort of signs and maybe traditional and simplified and be able to practice
> them in respect to each other.
> See bug #93446 (https://bugs.kde.org/show_bug.cgi?id=93446).
>
> Another thing is that this concept blows up the code unnecessarily and in a
> ugly way. Because everywhere there is special treatment for original, than
> an iteration over all translations.
> KVocTrain and also the lib we have about thousand places like (rather small
> example of duplicate code directly next to each other):
>
> (from keduvocdocument.cpp)
> if (sort_column == 0)
>             return e1.original().toLower() < e2.original().toLower();
>          else
>             return e1.translation(sort_column).toLower() <
> e2.translation(sort_column).toLower();
>
> This will become:
> return e1.translation(sort_column).toLower() <
> e2.translation(sort_column).toLower();

The other big change is the use of lessons. To make KEduVocDocument a little 
cleaner I would like to remove all references to lessons and vocabulary 
entries, exept having it contain a single lesson.

Lessons would actually contain their vocabulary and can contain sublessons.
This makes organization much nicer and removes many special case treatment as 
well.

Types should actually be a real class to fix bug #138488, that it was 
impossible to query for nouns and have noun:male/femal/nutral included.

The multiple choice class was a really weird container for five QString. I'd 
replace it with a QStringList which is more flexible and smaller. This also 
get's rid of the fixed maximum of multiple choice answers.

Also I'd like to drop built in usages/types/tenses.
So far there are constants defining these in a rather ugly way and they cannot 
be deleted. My suggestion is to create them like normal user defined 
usages/types/tenses at the time the document is created and from there on let 
the user do with them what he wants.


Internally:
-get rid of everything original() and the like - this is pure code 
duplication! Also see bug #93446 
(https://bugs.kde.org/show_bug.cgi?id=93446).
-move all lesson stuff into the lesson class
-move all entry/expression stuff into the lesson class
-create a class translation inside the entry class, containing everything that 
is language specific (conjugation, article, the expression in the respective 
language)
-create a grading class inside the translation class to hold all grades (to 
the respective language, with a remark from which other language, to enable 
statistics)
-make many classes nicer (conjugation, article, ...)
After all this is done, redoing the actual reader/writer classes will be easy. 
There are also many places to optimize, but changing the internal classes 
should come first and can be done gradually.

I forgot probably a thousand issues, but they'll pop up, I'm sure of it.

Have a great day!
Frederik


PS: is there any reason for the name kdeeducore of the lib folder? I'd rather 
rename it to libkvtml/libvocabulary/... or something meaningfull.

["kvtml_empty_sample.kvtml" (text/x-objcsrc)]

/***************************************************************************
                   Vocabulary Document for KDE Edu
    -----------------------------------------------------------------------
    copyright     : (C) 1999-2001 Ewald Arnold
                    (C) 2001 The KDE-EDU team
                    (C) 2005, 2007 Peter Hedlund <peter.hedlund@kdemail.net>
                    (C) 2007 Frederik Gladhorn <frederik.gladhorn@kdemail.net>
 ***************************************************************************/

/***************************************************************************
 *                                                                         *
 *   This program is free software; you can redistribute it and/or modify  *
 *   it under the terms of the GNU General Public License as published by  *
 *   the Free Software Foundation; either version 2 of the License, or     *
 *   (at your option) any later version.                                   *
 *                                                                         *
 ***************************************************************************/

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE kvtml SYSTEM "kvoctrain.dtd">
<kvtml version="2.0.0">
  <information>
    <generator></generator>
    <title></title>
    <author></author>
    <license></license>
    <comment></comment>
  </information>

  <identifiers>
    <indentifier id="0">
      <type>user|language|...</type>
      <twoalpha></twoalpha>
      <name></name>
      <comment></comment>
      <sizehint>250</sizehint>

      <article>
        <definite>
            <male>der</male>
            <female>die</female>
            <nutral>das</nutral>
        </definite>
        <indefinite>
            <male>ein</male>
            <female>eine</female>
            <nutral>ein</nutral>
        </indefinite>
      </article>
/** @todo There is a bug about spanish articles - concerning "lo". I cannot really take it serious, but \
maybe a little research would be good. "lo" is used to make a noun out of other things, so tecnically I \
have no clue if that is an article. Language lawyers here please! What category is it? */
      <conjugation>
        <singular>
            <firstPerson>ich</firstPerson>
            <secondPerson>du</secondPerson>
            <thirdPerson>
                <male>er</male>
                <female>sie</female>
                <nutral>es</nutral>
            </thirdPerson>
        </singular>
        <plural>
            <firstPerson>wir</firstPerson>
            <secondPerson>ihr</secondPerson>
            <thirdPerson>
                <common>sie</common>
            </thirdPerson>
        </plural>
// of course third person can instead have individual entries
      </conjugation>
    </identifier>
  </identifiers>


  <types>
    <type>grammar type a</type>
    <type>grammer type b</type>
  </types>
// subtypes would be nice - hierachical structure...
  <tenses>
    <tense>Special tense</tense>
  </tenses>

  <usages>
    <usage>slang usage</usage>
    <usage>professional usage</usage>
  </usages>
/// @todo should they have an id attribute? Or are we using order only? Should be possible here.

  <lessons>
    <lesson>
      <name>Lesson with grades example</name>
      <query>true</query>
      <current>true</current>*/

    <entry>
      <inactive>true</inactive> to deactivate an entry (won't be queried)
      <inquery>true</inquery>
      <sizehint>25</sizehint>     // kwordquiz wants different cell heights
         <translation id="0">
           <text>Kniebeugen</text>
           <type></type>
           <inquery>1</inquery>
           <comment></comment>
           <pronunciation></pronunciation>
           <falsefriendfrom></falsefriendfrom>
           <falsefriendto></falsefriendto>
           <falsefriend></falsefriend>
           <antonym></antonym>
           <synonym></synonym>
           <example></example>
           <usage></usage>
           <paraphrase></paraphrase>
           <comparison>
             <comp1>gut</comp1>
             <comp2>besser</comp2>
             <comp3>am besten</comp3>
           </comparison>
           <multiplechoice>
             <choice></choice>
             <choice></choice>
           </multiplechoice>

           <image></image>
           <sound></sound>
///@todo we need classes for image and sound! What to display, if the image is not found? A name tag? The \
translation? We can define the real contents of these tags later, I guess...

 GRADING:
           <grade fromid="1">
             <currentgradeint>1</currentgradeint>
             <count>1</count>
             <errorcount>1</errorcount>
             <date>949757271</date>
           </grade>
         </translation>
         <translation id="1">
           <text>genuflect</text>
           <grade fromId="0">
             <currentgradefloat>0.8</currentgradefloat>
             <count>6</count>
             <errorcount>1</errorcount>
             <date>949757271</date>
           </grade>
         </translation>
       </entry>
     </lesson>
   </lessons>
 </kvtml>


[Attachment #8 (application/pgp-signature)]

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

Configure | About | News | Add a list | Sponsored by KoreLogic