[Kolab-devel] XML Storage format questions

[Hendrik Helwich]

Hi Bernhard,

thanks for the advice.


Bernhard Reiter schrieb:
> 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.
>
>   

Ok. So we will check the cvs history of the sgml files to be sure this
schema is still up to date.

> 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.)
>
>   

I am aware that the schema is only a small part of the validation
process, but anyhow it is useful to us because we can do an automatic
first validation. Other format constraints will be checked based on the
kolab xml format specification.
We will take the following code to fill the gap when the kolab xml
format specification is not as detailed as needed:

http://files.kolab.org/apt/releases/dists/lenny/unstable/source/kdepim_3.5.10.enterprise.0.20100409.1112955.orig.tar.gz

Best regards,

Hendrik

>> 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
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


-- 
Besuchen Sie uns vom 09.06. bis zum 12.06. auf dem LinuxTag 2010
an unserem Stand „Fairtrade Software“ (Halle 7.2a. / Stand 123)!
Unsere Themen dieses Jahr:    • Evolvis • Freedroidz • Portale •
       • Identity and Access Management • Mobile Applikationen •

tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH
Geschäftsführer: Boris Esser, Elmar Geese
HRB AG Bonn 5168 - USt-ID (VAT): DE122264941

Heilsbachstraße 24, 53123 Bonn,   Telefon: +49 228 52675-0
Weigandufer 45,     12059 Berlin, Telefon: +49 30 5682943-30
Internet: http://www.tarent.de/ • Telefax: +49 228 52675-25