event XML 1.1 (fix recurrances)
Joon Radley
joon at radleys.co.za
Thu Feb 8 17:24:19 CET 2007
Hi Gerd,
> Sorry, but I have to disagree.
Did I miss something again, <exclusion> is for deleted exceptions, so are
<subevent> deleted events that are not deleted?
Keeping the <exclusion> tag for deletions and <subevent> for "modified"
recurrences needs no matching between the 2 sets of tags.
> 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.
How is this implemented in Kontact? The root tag preservation was the
original design, I have no idea why it was not in the original spec.
Yes it would be cool to have but it will also be very problematic. I will
bet you that this would become the single biggest interoperability issue
between all clients.
Best Regards
Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joon at radleys.co.za
Web: www.toltec.co.za
> -----Original Message-----
> From: Gerd v. Egidy [mailto:gerd.von.egidy at intra2net.com]
> Sent: 08 February 2007 05:09 PM
> To: kolab-format at kolab.org
> Cc: Joon Radley; 'Martin Konold'
> Subject: Re: event XML 1.1 (fix recurrances)
>
> 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
>
> <recurrence>
> ...
> <exclusion>date1</exclusion>
> <exclusion>date2</exclusion>
> </recurrence>
> <subevent>
> <original-date>date1</original-date>
> <start-date>new-date1</start-date>
> ...
> </subevent>
> <subevent>
> <original-date>date2</original-date>
> <start-date>new-date2</start-date>
> ...
> </subevent>
>
> 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
>
> <recurrence>
> ...
> <exclusion>date1
> <subevent>
> <start-date>new-date1</start-date>
> </subevent>
> </exclusion>
> </recurrence>
>
> 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
> <contact>
> - ...
>
> 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,
>
> Gerd
More information about the format
mailing list