Thread 2: On recurrence exceptions

[Bernhard Reiter]

Georg,

thanks for pushing the issue, we really should make progress here soon.

On Wednesday 03 November 2010 10:43:07 Georg C. F. Greve wrote:
> The proposal at the time was to introduce two new tags,
>
>   * <exclusion> - to model exceptions from recurrence
>   * <subevent> - to model single instance modifications

Rereading the email I believe Martin only wanted to introduce
"<subevent>" which could be used once per exclusion to hold 
the difference to the original event that is repeated.

> This is what the Kolab specification says about tags that are not
> understood:
>
>  "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.

In the emails referenced by Martin, Joon stated that preserving
only tags below <event> was the idea of Joon and Bo when they worked out the 
first format description. Their reasons where technical difficulties.
Participants seems to have agreed that some technical difficulty is there to
preserve tags everywhere.

David and Joon both stated that Toltec 2 and Kontact do only preserve
tags under <event> and Kontact does not even preserve subtags of that 
preserved tag. When considering backwarts compatibility we need to keep that 
in mind. We will not be fully compatible if real old clients fail here.
(Just stating the fact, we could decide to go without that compatibility.)

> So this approach would be backward compatible, and exceptions should this
> way not be broken/stripped out by existing/older clients.
>
> XML wise, it would look like this:
>
> <recurrence>
>         ...
>         <exclusion>
>                 date
>                 <subevent>
>                         ...
>                 </subevent>
>         </exclusion>
> </recurrence>
>
> So the exclusion would "break" the chain, and if no subevent exists, this
> instance is simply cancelled. Where a subevent exists, it models ONLY the
> modification for this ONE instanc - and inherits everything else from the
> parent.
>
> This seems a sensible and robust solution to me, and perfectly in line with
> the Kolab design, so I'd like to invite input as to issues this would not
> resolve or even cause, as well as counter-proposals.

I agree that the general idea is good, we should check a few things
to move forward with it:

One variant was to use <subevent> below <recurrance> to be able to get 
compatible behaviour from old Toltec and Kontact. We probably should test this 
if Kontact did not implement preserving tags within <subeventY when used this 
way.

I am unsure how things will work with invitation handling. We also need to 
check this with iTip and with the implementations. I know that iCalendar 
allows for a lot of stuff, and if it allows for one appointment to be so 
fragmented, this would pose a problem for user interfaces of accepting 
invitations and updates. If this is the case, we should consider a proposal
where the subevent is created as a seperated event and we introduce something 
like a link from the top to the subevent.

The <howeverlink> could be designed to be backwards compatible
and invitatins would treat the new event as a single new event
which I believe could be easier on the flow of interactions and thus
on the user interfaces and interaction.

What do you think?

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Germany Coordinator: fsfeurope.org. Coordinator: Kolab-Konsortium.com.
Intevation GmbH, Neuer Graben 17, Osnabrück, DE; AG Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101117/690419fa/attachment.sig>