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">[EMAIL PROTECTED]</
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
