event XML 1.1 (fix recurrances)

[Joon Radley]

Hi Gerd,

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

> Data in new spec, changes as subevent, old client:
> The client will display the recurrence. The changed single event will be
> excluded and not shown. If the client is conforming to the spec, it will
> write out the <exclusion> including the <subevent> if the event is
> changed. No data is lost.

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. Keeping unknown
tags at the root object make implementation much simpler.

> If Toltec doesn't preserve tags it does not understand (e.g. the proposed 
> <subevent> within the <exclusion>), it would violate a MUST requirement
> of the current spec.

As long as the tag is in the root of the XML object it will be preserved.

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: kolab-format-bounces at kolab.org [mailto:kolab-format-
> bounces at kolab.org] On Behalf Of Gerd v. Egidy
> Sent: 07 February 2007 07:39 PM
> To: kolab-format at kolab.org
> Cc: 'Martin Konold'; Joon Radley
> Subject: Re: event XML 1.1 (fix recurrances)
> 
> Hi Joon,
> 
> > The migration is a major undertaking and I needs to be worked out to
> the
> > very  last detail. I do understand that migration is not a big issue
> to
> > you, but  for us it is.
> 
> I don't know about Martin, but for me compatibility and migration is an
> issue.
> 
> But lets discuss compatibility of the current spec (2.0rc5 as on
> kolab.org)
> with the changes Martin is proposing.
> 
> The current spec only allows to exclude events from the recurrence, not
> to
> change them. This is done via <exclusion>date</exclusion>. So if you
> want to
> change single events with the current spec, A) you either can't do it
> or B)
> you exclude one single event from the recurrence and create a separate
> event
> for it, losing the link between the two.
> 
> With Martins proposal, the changes are stored below <exclusion>s to
> allow
> compatibility:
> 
> <recurrence>
> 	...
> 	<exclusion>
> 		date
> 		<subevent>
> 			...
> 		</subevent>
> 	</exclusion>
> </recurrence>
> 
> So what happens is this:
> 
> Data in old spec, changes as separate event (B), new client:
> No loss of data, no loss of functionality
> 
> Data in new spec, changes as subevent, old client:
> The client will display the recurrence. The changed single event will
> be
> excluded and not shown. If the client is conforming to the spec, it
> will
> write out the <exclusion> including the <subevent> if the event is
> changed.
> No data is lost.
> 
> I think this is as far as we can go regarding compatibility and new
> features.
> We just can't add new features if we insist all existing clients must
> understand them.
> 
> > If you feel that there is just no way you can wait, please define the
> sub
> > events in the root of the object
> 
> So you propose something like this:
> 
> <recurrence>
> 	...
> 	<exclusion>date1</exclusion>
> 	<exclusion>date2</exclusion>
> </recurrence>
> <subevent>
> 	date1
> 	...
> </subevent>
> <subevent>
> 	date2
> 	...
> </subevent>
> 
> This was Martins first idea. But this makes the format more complicated
> because you have to make sure that the <exclusion> and <subvent> tags
> always
> match.
> 
> The current proposal "codes" this requirement directly into the xml-
> syntax and
> thus needs no explicit description.
> 
> > so that they stay preserved by Toltec.
> 
> If Toltec doesn't preserve tags it does not understand (e.g. the
> proposed
> <subevent> within the <exclusion>), it would violate a MUST requirement
> of
> the current spec.
> 
> Kind regards,
> 
> Gerd
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format