Kolab XML Format: The xCal/xCard based approach

Fri Nov 18 22:01:59 CET 2011

On Thursday 17 November 2011 14.08:14 Thomas Koch wrote:
> 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?
> 

Hey Thomas,

As far as I understand it xCal/xCard doesn't specify how to store single 
events/todos etc. but only how to store a complete calendar. Also I had the 
intention to restrict the format => it's not really xCal/xCard.
This would also have implied that we need a version number => we need the 
kolab element at least for the version number. (We could have added the 
version number through the extension mechanisms of xCal too)

Latest discussion showed that we should rather strive for a fully compliant 
implementation (as far as possible)

I'll probably change the format to:

So almost fully compliant xCal, except that it is unspecified if you can 
actually store an event outside of a calendar(afaik).
> > 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?
> 

BYDAY in Recurrences depending on the CYCLE, from the top of my head.

> > 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.h
> tml
> > 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?
> 

IMO the difference is that a journal is associated to a specific time, so a "log 
entry". A note is just a general piece of information, not associated with a 
specific time.

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

Because it sucks to implement =)
Remember that a client implementation has to preserve that information 
somehow. Of course it could be solved by identifying an element by an xpath 
and storing the a map of identifier value pairs, but there's not enough use in 
it compared to the additional work it generates.

> > 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]
> 

That is exactly using that extension mechanism.
It's just a further restriction which makes client implementations easier.

> > (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! :-))
> 

It is IMO a perfectly valid argument. Especially considering that just one not 
fully complying client implementation essentially breaks the whole concept and 
results in data-loss.

The second argument is: what is it good for?
I reckon also with our limited version all possible usecases are covered.

Last but not least, it doesn't necessarily help the format to provide all 
possible extension mechanism. It is very much in our interest to get vendor 
extension into the format and not having everyone implementing their own 
little extensions.

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

Agreed, that is ideally the way we want to go. The question is to what extent 
this is actually feasible.

Cheers,
Christian

> Best regards,
> 
> Thomas Koch, http://www.koch.ro
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20111118/109d366d/attachment.sig>