event XML 1.2.1 (fix recurrances)

Fri Jan 26 00:51:03 CET 2007

Am Mittwoch, 17. Januar 2007 11:16 schrieb Martin Konold:

Hi,

this is a new updated version 1.2.1 (draft) improved with the feedback from 
Gerd and Joon.

===== Open Issues with Kolab XML Format for events ========================
I1: - Howto handle attendees in subevents? (Joon)
I2: - Howto handle attachments in subevents? (Joon)
I3: - Howto handle <body> in subevents? (me)
I4: - Howto improve <body> (use something more rich than plain ASCII) (me,
      Gerd)
I5: - Investigate merging new <body> with attachments (me)
I6: - How to improve the semantic of <priority>
I7: - How to deal with the privacy setting
============================================================================

Basically version 1.2.1 it is the well known old 1.0 format with a single
additional tag <subevent></subevent>.

<subevent> is nested within an <exclusion></exclusion> pair in order to 
express the dependency explicitly in the syntax.

I also added <priority> also to <events> and <subevents>. Please note that
we need to fix the priority field anyway. (separate discussion).

To my knowledge this enhanced format is able to describe all known kinds of
events which are possible in Microsoft Outlook 2k-2k7.

In some respects the purpose of this format is a superset of the 
funtionalities provided by Kolab clients. 

Kolab clients which cannot suport a feature or tag must at least preserve it.

The issue I3 about the detailed syntax of <body> is to be discussed seperately 
and the result will be incorporated into this Kolab event XML Format 
definition. This will then also have an impact on how attachments will work. 
The definition of the syntax and semantic of the <body> tag is generic and 
unrelated to this recurrance discussion. 

<?xml version="1.0" encoding="UTF-8"?>
   <event version="1.2.1">
   <!-- Common fields -->
   <uid>(string, no default)</uid>
   <body>(string, default empty)</body>
   <categories>(string, default empty)</categories>
   <creation-date>(datetime, no default)</creation-date>
   <last-modification-date>(datetime, no default)</last-modification-date>
   <sensitivity>(string, default public)</sensitivity>
   {<inline-attachment>(string, no default)</inline-attachment>}
   {<link-attachment>(string, no default)</link-attachment>}
   <product-id>(string, default empty)</product-id>
   <!-- Incidence fields -->
   <summary>(string, default empty)</summary>
   <location>(string, default empty)</location>
   <organizer>
     <display-name>(string, default empty)</display-name>
     <smtp-address>(string, default empty)</smtp-address>
   </organizer>
   <start-date>(date or datetime, default not present)</start-date>
   <end-date>(date or datetime, default not present)</end-date>
   <color-label>(string, default none)</color-label>
   <priority>(number, default not present</priority>
   <show-time-as>(string, default busy)</show-time-as>
   <alarm>(number, no default)</alarm>
   <recurrence cycle="cycletype" [type="extra type"]>
     <interval>(number, default 1)</interval>
     {<day>(string, no default)</day>}
     <daynumber>(number, no default)</daynumber>
     <date>(number, no default)</date>
     <month>(string, no default></month>
     <range type="rangetype">(date or number or nothing, no default)</range>
     {<exclusion>(date, no default)
        <!-- sub events -->
        <!-- one subevent per exclusion is allowed. All subtags of subevent
             are by default "not present" and inherit their values from the
             primary event if they are not explicitly set. Basically this
             means that mainly the difference towards the primary event is
             stored in subevents! -->
       {<subevent>
          <summary>(string, default not present)</summary>
          <location>(string, default not present)</location>
          <start-date>(date or datetime, default not present)</start-date>
          <end-date>(date or datetime, default not present)</end-date>
          <alarm>(number, default not present)</alarm>
          <color-label>(string, default not present)</color-label>
          <priority>(number, default not present</priority>
          <show-time-as>(string, default not present)</show-time-as>
          {<attendee> <!-- attendee is optional but if present the
                           list of attendees must be complete! -->
          <display-name>(string, default empty)</display-name>
          <smtp-address>(string, default empty)</smtp-address>
          <status>(string, default none)</status>
          <request-response>(bool, default true)</request-response>
          <role>(string, default required)</role>
          </attendee>}
          {<inline-attachment>(string, no default)</inline-attachment>}
          {<link-attachment>(string, no default)</link-attachment>}
       </subevent>}
     </exclusion>}
   </recurrence>
   {<attendee>
     <display-name>(string, default empty)</display-name>
     <smtp-address>(string, default empty)</smtp-address>
     <status>(string, default none)</status>
     <request-response>(bool, default true)</request-response>
     <role>(string, default required)</role>
   </attendee>} 
 </event>

The following is new in Kolab XML Format 1.2.1
- allow multiple attachments in subevents

- new tag <subevent></subevent>
This tag may occur multiple times exclusivly as a subtree element of an
<exclusion> tag.

- The following explicit list of tags is allowed within a subevent:

{<subevent>
     <summary>(string, default not present)</summary>
     <location>(string, default not present)</location>
     <start-date>(date or datetime)</start-date>
     <end-date>(date or datetime</end-date>
     <alarm>(number, default not present)</alarm>
     <color-label>(string, default not present)</color-label>
     <show-time-as>(string, default not present)</show-time-as>
     <priority>(number, default 5)</priority>
     {<attendee> <!-- default not present - if present the
                      list of attendees must be complete! -->
           <display-name>(string, default empty)</display-name>
           <smtp-address>(string, default empty)</smtp-address>
           <status>(string, default none)</status>
           <request-response>(bool, default true)</request-response>
           <role>(string, default required)</role>
     </attendee>}
     {<inline-attachment>(string, no default)</inline-attachment>}
     {<link-attachment>(string, no default)</link-attachment>}
</subevent>}

- If a tag is not present in a <subevent> the value is inherited from the
primary <event>.

- If no <attendee> is listed in a <subevent> the list of attendees is
inherited from the primary <event>. If there is any change to any member of
the list of attendees then all attendees must be listed in the <subevent>
entry. All <attendee> entries must be complete and there is no inheritence
involved with regards to subtree elements of <attendee>. E.g if the
<status> of an <attendee> is changed for a subevent the complete list of
all attendees must be included in the subevent and all tags except the
<status> tag are repeated unchanged in the subevent.

- The concluding list of allowed tags below <subevent> is:

<summary>(string, optional)</summary>
 <location>(string, optional)</location>
 <start-date>(date or datetime, mandatory)</start-date>
 <end-date>(date or datetime, mandatory</end-date>
 <alarm>(number, optional)</alarm>
 <color-label>(string, optional)</color-label>
 <show-time-as>(string, optional)</show-time-as>
 <priority>(number, optional)</priority>
 {<attendee>} 
           <display-name>(string, optional)</display-name>
           <smtp-address>(string, optional)</smtp-address>
           <status>(string, optional)</status>
           <request-response>(bool, default true)</request-response>
           <role>(string, default "required", optional)</role>
 </attendee>}
 {<inline-attachment>(string, optional)</inline-attachment>}
 {<link-attachment>(string, optional)</link-attachment>}

- as the above list of fields is concluding tags like <recurrence> or  
<sensivity> are disallowed within a <subevent>!

Yours,
-- martin

-- 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Stuttgart - Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/