event XML 1.1 (fix recurrances)
Gerd v. Egidy
gerd.von.egidy at intra2net.com
Thu Feb 8 16:08:49 CET 2007
> > 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
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
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.
More information about the format