Kolab XML Format: The xCal/xCard based approach

[Thomas Koch]

Hi Christian,

nice summary, especially as we independently came to similiar conclusions. :-)
Comments inline.

Christian Mollekopf:
> Hey,
> 
> 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 
maximal compatibility.

> 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[4], 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:
http://lists.calconnect.org/pipermail/caldeveloper-l/2011-November/000115.html

> 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
> supported.
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
> "x-kolab-customproperty":
> 
>   <x-kolab-customproperty>
>           <identifier>vendor-custom-value</identifier>
>           <value>value</value>
>   </x-kolab-customproperty>
Why not use the extension mechanisms defined for xCal/xCard? [rfc5545,sec 
3.8.8;rfc6350,sec 6.10]

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

Best regards,

Thomas Koch, http://www.koch.ro