event XML 1.1 (fix recurrances)

[Gerd v. Egidy]

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