Kolab XML Format: The xCal/xCard based approach
Christian Mollekopf
mollekopf at kolabsys.com
Tue Nov 15 13:32:02 CET 2011
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
More information about the format
mailing list