[Kolab-devel] XML Storage format questions (Re: New Evolution-to-Kolab2 Project)

[Bernhard Reiter]

Hi Hendrik,

Am Dienstag, 8. Juni 2010 15:16:07 schrieb Hendrik Helwich:
> i am also working on the project to integrate Evolution with the Kolab
> Server and does have some questions related to reading/writing the Kolab
> Xml format. I would be glad if you could give me some hints :-)

welcome to the Kolab initiative! 
We will try our best to help you out of course!
Note that there is also a seperate format discussion list, 
https://kolab.org/mailman/listinfo/kolab-format
It did not see much traffic, but that might change in the future.
[I am sending a copy there, please choose one list to reply at your liking.]

> We need to transform the Contact Xml type of the Kolab Xml format [1] to
> the vCard format and The Kolab Event/Task/Journal Xml type to the iCal
> format.
> We also want to integrate this converter code in the evolution code base
> and therefore must have only "gnome-dependencies" like libXml2 and Glib.
>
> Is there some code available for that purpose?

I don't know. Kolab Webclient based on the Horde libraries and KDE Kontact 
will have code for vCard and iCalender format export and iTIP handling of 
course. What I am unsure of is the internal data representation within them.
I believe that Kontact e35 used vCard and iCalender internally so there must 
be code for it, I hope that Kontact E5 will not use this as an internal 
format. I do expect issues on the translation 
Kolab XML storage object <-> iCalender / vCard storage object
if the iCalendar /VCard storage object is independently manipulated without 
keeping further restraints.

> I think the reference code for doing this things on kde is located here:
> http://websvn.kde.org/trunk/KDE/kdepim/runtime/resources/kolabproxy/
> Am i right?

This looks like the new KDE4 implementation. The KDEPIM people will know for 
sure https://mail.kde.org/mailman/listinfo/kde-pim .

> Is a similar gnome implementation available or is there some code we can
> adapt to fit our needs?

At least I haven't heard about it so far. 

> I found this relax NG Schema in the kolab cvs repository:
> http://kolab.org/cgi-bin/viewcvs-kolab.cgi/*checkout*/doc/kolab-formats/val
>idation/kolab-storage.rng?rev=1.17 Can it be used for validation purposes? I
> wonder because i did not find a link to it from the kolab format
> description page [1]. Is this schema still up to date?

That would need to be checked. I guess it would need some smaller updated.
You should be able to check that if you track changes in the Kolab XML format
specification.

Note that formal validation will mostly only catch the less interessting 
issues. We  figured that we would need a client implementors manual
which defines behaviour beyond the current XML specification.
So whereever the XML specification lacks, compatibility with the reference 
clients KDE Kontact proko2 and Outlook/Toltec2 will fill the gap.
(Yes Kontact e35 should be closesed to proko2 and still be maintained if you 
need something to run. So it is a really good idea to keep an installation of
e35 around to check behaviour.)

> As it is defined here [2], it is allowed to write client specific tags
> to the Kolab Xml. This client specific content must be preserved if we
> convert the Xml to vCard/iCal and back to the Kolab Xml.
> Is there a preferred way for doing so?

Check how Toltec and Kontact do it. 

> Are there any limitations on how the client specific tags can occur in
> the Xml (e.g. only top level) or on its structure (e.g. only flat
> elements) or is it allowed to write client specific elements at any
> position in the Kolab Xml tree?

I would probably limit it to toplevel tags within a storage object.
Ultimately it would be interesting to see how the clients deal with it.
That is another important goal: We want to keep compatibility with the 
clients. So testing how a few of the other clients behave towards something
is always a good idea as well.

> [1] http://www.kolab.org/doc/kolabformat-2.0rc7-html/index.html
> [2] http://www.kolab.org/doc/kolabformat-2.0rc7-html/x123.html

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20100609/b82ba933/attachment.sig>