event XML 1.1 (fix recurrances)

[Joon Radley]

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