[Dev] The Chandler/Cosmo sharing format

Lisa Dusseault lisa at osafoundation.org
Mon Mar 6 16:05:19 PST 2006


The xCalendar proposal is currently not going anywhere, and no other  
vendors have proposed to support it.  They ask, rightly, "why  
bother".  xCalendar isn't in itself any more extensible than iCalendar.

Got any answers that might inspire people to adopt xCalendar? (My  
answers are a little weak and involve XMPP and Atom, not pure CalDAV)

Lisa

On Mar 6, 2006, at 11:59 AM, Morgen Sagen wrote:

>
> On Mar 5, 2006, at 8:58 AM, Brian Moseley wrote:
>>
>> in the chandler repository, an item is basically just a list of types
>> and a flat list of name/value pair style attributes, right?  
>> couldn't a
>> very simple xml format address that in a flexible way?
>>
>> <cosmo:item primarytype="cosmo:event" mixintypes="cosmo:contact,  
>> cosmo:msg">
>>   <cosmo:attr cosmo:name="summary" cosmo:created="xxx"
>> cosmo:modified="xxx" cosmo:who="bcm">this is an item</cosmo:attr>
>>   <cosmo:attr cosmo:name="firstname" cosmo:created="xxx"
>> cosmo:modified="xxx" cosmo:who="bcm">brian</cosmo:attr>
>>   <cosmo:attr cosmo:name="to" cosmo:created="xxx"  
>> cosmo:modified="xxx"
>> cosmo:who="ticket-cafebebedeadbeef">lisa at osafoundation.org</ 
>> cosmo:attr>
>> </cosmo:item>
>
> I think I'd propose we use the xCalendar standard for representing  
> iCalendar data in XML, and bundling those xCalendar elements within  
> a general item representation using namespaces to qualify the  
> attributes -- something along the lines of:
>
> <core:item
>         xmlns:ical="http://www.ietf.org/rfc/RFC2445.txt"
> 	xmlns:core="http://osafoundation.org/schemas/core/0.1"
> 	xmlns:pim="http://osafoundation.org/schemas/pim/0.1">
>
>     <!-- 'Core' attributes living on ContentItem -->
>     <core:title>New Event</core:title>
>     <core:description>Some description of the item</core:description>
>     <core:uuid>a93aa9f6-6f3a-11da-a2d4-000a95bb2738</core:uuid>
>     <core:date-created>2006-03-03 12:21:9.890080</core:date-created>
>     <core:date-modified>2006-03-03 15:32:9.900080</core:date-modified>
>     <core:body mimetype='text/plain'  
> encoding='utf-8'>SGVyZSBpcyB0aGUgdGV4dCBvZiB0aGUgbm90ZQ==</core:body>
>
>     <!-- 'Calendar Event' attributes -->
>     <pim:isEvent>True</pim:isEvent>
>     <ical:vcalendar xmlns:ical="http://www.ietf.org/rfc/RFC2445.txt"
>         <ical:version>2.0</ical:version>
>         <ical:prodid>-//PYVOBJECT//NONSGML Version 1//EN</ical:prodid>
>         <ical:vtimezone>
>             <ical:tzid>US/Pacific</ical:tzid>
>             <ical:standard>
>                 <ical:dtstart>20001029T020000</ical:dtstart>
>                 <ical:rrule>FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10</ 
> ical:rrule>
>                 <ical:tzname>US/Pacific</ical:tzname>
>                 <ical:tzoffsetfrom>-0700</ical:tzoffsetfrom>
>                 <ical:tzoffsetto>-0800</ical:tzoffsetto>
>             </ical:standard>
>             <ical:daylight>
>                 <ical:dtstart>20000402T020000</ical:dtstart>
>                 <ical:rrule>FREQ=YEARLY;BYDAY=1SU;BYMONTH=4</ 
> ical:rrule>
>                 <ical:tzname>US/Pacific</ical:tzname>
>                 <ical:tzoffsetfrom>-0800</ical:tzoffsetfrom>
>                 <ical:tzoffsetto>-0700</ical:tzoffsetto>
>             </ical:daylight>
>         </ical:vtimezone>
>         [...]
>     </ical:vcalendar>
>
>     <!--  Attributes from other mixins follow...  -->
>     [...]
>
> </core:item>
>
> Cosmo would only have to pay attention to the xCalendar elements  
> (those in the http://www.ietf.org/rfc/RFC2445.txt namespace) -- the  
> spec for that is at http://ietfreport.isoc.org/idref/draft-hare- 
> xcalendar/
>
>
>
>>
>> this would not make life difficult for cosmo. when processing a  
>> caldav
>> or atom request, it could easily convert this to icalendar or
>> hcalendar. when accepting an event from a caldav or atom client,  
>> cosmo
>> could convert the icalendar or hcalendar into this format for  
>> indexing
>> and storage.
>>
>> supporting a format like this would make cosmo very appealing for
>> clients other than chandler as well.
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev




More information about the Dev mailing list