event XML 1.1 (fix recurrances)

Gerd v. Egidy gerd.von.egidy at intra2net.com
Thu Feb 8 16:08:49 CET 2007

Hi Joon,

> > This was Martins first idea. But this makes the format more complicated
> > because you have to make sure that the <exclusion> and <sub-event> tags
> > always match.
> No it is no more complicated than embedding the sub-events in the exclusion
> tag as this matching must take place in the client. Having the sub-events
> in a container in the root of the object makes no difference to
> functionality, but does help a lot with compatibility between new and old
> clients.

Sorry, but I have to disagree.

If you have something like this


the format is more complicated because the client has to make sure that the 
<exclusion>s and the <subevent>s match each other. Defining it this way adds 
a constraint to the spec which is very hard to check automatically using 
common xml techniques.

But when you define it like this


the link between exclusion and subevent is implicitly coded into the format,  
easy to check and understand.

I do not understand why you think that there has to be any matching in the 
client with this format because exclusion and the corresponding new subevent 
are next to each other in the same xml node.

> So do you suggest that we introduce infinite depth tag preservation?
> Restricting unknown tag preservation to the root of the object was a design
> decision by both Bo and myself to avoid infinite depth tag preservation as
> it can be very complicated and error prone to implement. 

I do not suggest infinite depth tag preservation, it is already defined by the 
current spec, chapter 1.2:

If a client sees a tag it does not understand, this tag must be preserved and 
saved back to the file. This allows for client specific tags. Outlook writes 
it client specific tags directly in a tnef file that is saved as an 
unreferenced attachment.

I can't find any word in the spec telling me that tags at deeper levels are 
any different than tags at the top level. Even if it was a design decision 
back then it seems like it hasn't made it into the spec.

And I can easily come up with some ideas where it really makes sense to keep 
tags in deeper levels extensible:

- the <address> tag within <contact>, e.g. to add geo-coordinates
- the <attendee> tag within <event>, e.g. to add some kind of link to a 
- ...

I don't propose these additions now, I just think we should keep the door open 
and be able to later extend the format with stuff like this. I always liked 
this part of the kolab format because its commitment to forward-compatibility 
appeared to me as wise foresight.

Kind regards,


More information about the format mailing list