Kolab XML Format: The xCal/xCard based approach

[Christian Mollekopf]

Hey,

I'd like to line out my findings of my work on the kolab xml format. 
After my proposal for an xsd friendly update of the xml format, I 
continued to face problems with the XSD based implementation.
Surprisingly not due to the XSD but due to the limits of format 
specification. My fixes/workarounds ended up to be very close to the 
iCal(RFC5545)[1]/vCard(6350)[2] specifications  and with Georg finding 
the rather new xCal/xCard specification it became apparent that we would 
be much better off reusing these efforts, instead of reinventing the 
wheel. The iCal/vCard specifications are IMO fairly solid and way more 
powerful than what we have right now with the kolab format, meaning we 
can model all our current data in xCal, plus all the existing format 
related KEP's. I think it is also clear that no format field is useful 
without a UI for it, and since Kontact, as our main client, follows the 
iCal/vCard specification, we are in fact anyways forced to be very close 
to iCal/vCard.

Therefore I propose to switch to an xCal based format for events and 
todos and to xCard for contacts. xCal/xCard specify complete 
calendars/address-books in XML, while we only need single 
incidences/contacts. My proposed solution would look along the lines of 
this (just to give an idea):

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<event version="3.0" xmlns="http://kolab.org" 
xmlns:xcal="urn:ietf:params:xml:ns:icalendar-2.0">
   <xcal:vevent>
     <xcal:properties>
       <xcal:uid>
         <text>19970610T172345Z-AF23B2 at example.com</text>
       </xcal:uid>
       <xcal:dtstart>
         <parameters>
           <tzid>
             <text>US/Eastern</text>
           </tzid>
         </parameters>
         <date-time>2011-08-12T02:12:15</date-time>
       </xcal:dtstart>
       <xcal:rrule>
         <xcal:recur>
            <xcal:count>2</xcal:count>
           <xcal:byhour>3</xcal:byhour>
           <xcal:freq>DAILY</xcal:freq>
         </xcal:recur>
       </xcal:rrule>
       <x-kolab-customproperty>
          <identifier>vendor-custom-value</identifier>
          <value>value</value>
       </x-kolab-customproperty>
     </xcal:properties>
     <xcal:components>
       <xcal:valarm/>
     </xcal:components>
   </xcal:vevent>

</event>

The xcal:vevent is valid according to the xCal specification, the rest 
is kolab specific.

XSD is unfortunately not powerful enough to validate this format, 
meaning a pure XSD + databindings implementation is not possible. The 
main problem is that values change their constraints based on other 
values, which cannot be modelled in XSD. The idea is therefore to have a 
C++ implementation in a library (libkolabxml) which can be used by 
clients as well, doing the necessary validation and transformation 
from/to in-memory containers. For Python & PHP we would create bindings 
based on SWIG [3], so libkolabxml will provide a shared implementation 
for all systems/languages.
Internally this will still be based on XSD, but with additional 
validation and an actually usable API.

This will client developers also give the advantage that a format 
upgrade is only a simple update of libkolabxml (for minor updates where 
only optional values may be added).

== Implementation ==

The xCal implementation will likely be based on the calconnect 
schemas[4], for xCard there exist not schemas AFAIK, so a new 
implementation will be needed.
For notes I'm not aware of any suitable format, but since they are 
anyways simple containers it should be easy enough to define our own. 
One option would be to reuse the xCal journal specification.

The implementation will be transparent to the users of libkolabxml 
however.

== Extensibility ==

Preserving of custom "x-" properties, as specified in xCal, will not be 
supported.
Instead the only defined way of extending the format is to make use of 
"x-kolab-customproperty":

  <x-kolab-customproperty>
          <identifier>vendor-custom-value</identifier>
          <value>value</value>
  </x-kolab-customproperty>

This should be an extension mechanism which clients can actually 
implement, as the clients will need to store these "identifier"/"value" 
pairs in their native containers.
(In contrary to allow extensions everywhere in the format (as in xCal), 
which is a lot more difficult to implement)

== Backwards compatibility ==

Obviously the new format is not backwards compatible to the current 
one.
For future minor upgrades we can keep backwards compatibility, so newer 
versions of the library can read older versions of the format and no 
conversion is needed.
However, using older versions of the library with a newer version of 
the format will result in the loss of all new elements because they are 
not preserved.

== Summary ==

Summarizing the changes we would gain the following:
- A new format specification which is based on xCal/xCard as far as 
possible
- A much better specification of the value semantics in the iCal/vCard 
format (compared to the current kolab format specification)
- Therefore a trivial mapping to libraries like KCalCore (almost 1:1 
because of the same semantics)
- A C++ implementation with libkolabxml
- SWIG based bindings for libkolabxml

I'd like to emphasize that the relevant part is IMO not that we have a 
valid xCal/xCard implementation, respectively that i.e. the vevent 
element is valid xCal.
The important part is that the semantics of the values are the same as 
in iCal/vCard, which makes the mapping to other iCal/vCard based 
implementations a lot easier, respectively possible.
The xml format itself is actually not relevant for the user of 
libkolabxml as long as the value semantics don't change (Of course we 
still need a proper format definition besides libkolabxml).

This process would result in a KEP redefining the whole Kolab Format 
specification resulting in Kolab Format 3.0.
All existing KEP's would be taken into account for the new format.

With my best regards,

Christian

[1]http://tools.ietf.org/html/rfc5545
[2]http://tools.ietf.org/html/rfc6350
[3]www.swig.org
[4]www.calconnect.org/artifacts/ical-art.shtml

-- 
Christian Mollekopf
Software Engineer

Kolab Systems AG
Zürich, Switzerland

e: mollekopf at kolabsys.com
w: http://kolabsys.com

pgp: EA657400 Christian Mollekopf