Kolab XML Format: The xCal/xCard based approach
thomas at koch.ro
Thu Nov 17 14:08:14 CET 2011
nice summary, especially as we independently came to similiar conclusions. :-)
> I'd like to line out my findings of my work on the kolab xml format.
> Therefore I propose to switch to an xCal based format for events and
> todos and to xCard for contacts.
As I've written on monday ("kolab format history"), I also think that
xCal/xCard are definitely worth a look. And I'd even propose to aim for
> The xcal:vevent is valid according to the xCal specification, the rest
> is kolab specific.
Why not use valid xCal/xCard documents?
> 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.
Could you give examples for constraints that depend on other values?
> The xCal implementation will likely be based on the calconnect
> schemas, for xCard there exist not schemas AFAIK, so a new
> implementation will be needed.
I've reported an error in the calconnect xCal schemas without response so far:
> 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.
I thought notes and journals are just two words for the same thing?
> Preserving of custom "x-" properties, as specified in xCal, will not be
Why? I'll write a separate mail about my thoughts regarding IMAP as a common
store without any protection layer in between.
> Instead the only defined way of extending the format is to make use of
Why not use the extension mechanisms defined for xCal/xCard? [rfc5545,sec
> (In contrary to allow extensions everywhere in the format (as in xCal),
> which is a lot more difficult to implement)
Because sth. is difficult is not a very strong or convincing argument not do
it. (Try harder! :-))
> 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.
Aiming for full compatibility would have the advantage that shared xCal/xCard
libraries could be used and developed together with other pim projects.
Thomas Koch, http://www.koch.ro
More information about the format