RFC: KEP3: Introduction of 'subevent' sub-tag for 'exclusion' from 'recurrence' (revision #10661 2 uses cases for <exception><subevent><deleted> and <exception><subevent><exceptionStartDate>

Alain Abbas alain.abbas at libertech.fr
Mon Dec 13 11:03:46 CET 2010


Sorry Georg we were talking of the same thing. i didnt read well the 
draft and  didnt understand  that 
there are n+1 exclusions.

My apologizes :-)


Georg C. F. Greve a écrit :
> Hi Alain,
>
> Thanks for providing some more details! :)
>
> On Sunday 12 December 2010 17.27:38 Alain Abbas wrote:
>   
>> step 2 :
>> modify the subject one one of the occurence
>>     
>
> This example seems to deviate from the current specification, no?
>
> Right now an exception would be modeled as
>
> <recurrence cycle="*daily*">
>   <interval>1</interval>
>   <range type="*number*">5</range>
>   <exclusion>EXCEPTIONDATE</exclusion>
> </recurrence>
>
> which means that on EXCEPTIONDATE, the recurrence does not take place, the 
> event has been deleted. Now if it has been modified, e.g. the summary as in 
> your example, according to KEP 3 it would look like this:
>
> <recurrence cycle="*daily*">
>   <interval>1</interval>
>   <range type="*number*">5</range>
>   <exclusion>EXCEPTIONDATE
>     <subevent>
>        <summary>Changed summary </summary>
>        <creation-date>DATE</creation-date>
>        <last-modification-date>DATE</last-modification-date>
>     </subevent>
>   </exclusion>
> </recurrence>
>
> The change of the start date according to KEP 3 would look like this:
>
> <recurrence cycle="*daily*">
>   <interval>1</interval>
>   <range type="*number*">5</range>
>   <exclusion>EXCEPTIONDATE
>     <subevent>
>        <start-date>NEW DATE</start-date>
>        <creation-date>DATE</creation-date>
>        <last-modification-date>DATE</last-modification-date>
>     </subevent>
>   </exclusion>
> </recurrence>
>
> Both of these would give you the "root date" of the exception, which also MUST 
> be used for Recurrence ID in iTIP handling. And it would maintain full 
> backward compatibility, whereas  your suggestion seems to break it entirely. 
> That may be justified if there is a major advantage to be gained - but what 
> that might be escapes me right now.
>
> So what is the major advantage of the different approach?
>
> Best regards,
> Georg
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format
>   




More information about the format mailing list