[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: oBIX encoding for iCalendar
Based on our last conference call, the strategy for oBIX scheduling
looks something like this: 1) Start with the iCalendar terminology, object
model, and semantics 2) Define the appropriate subset of iCalendar
applicable to control systems 3) Define an oBIX encoding for representing iCalendar
objects as native oBIX XML 4) Define bindings that could be used for scheduling
and schedule discover (bit vague right now) This email throws out some ideas on issue 3 – how to
model iCalendar as oBIX objects and contracts. Lets take a very simple
iCal event (the one defined by the Wikipedia): BEGIN:VCALENDAR VERSION:2.0 PRODID:-//hacksw/handcal//NONSGML v1.0//EN BEGIN:VEVENT DTSTART:19970714T170000Z DTEND:19970715T035959Z SUMMARY:Bastille Day Party END:VEVENT END:VCALENDAR
This is a simple event from 14 Jul 97 17:00 through 15 Jul 97 3:59:59 (times in UTC). The basic model is a “vcalendar” object which contains a “vevent” object. The “vevent” object defines a series of properties: “dtstart”, “dtend”, and “summary”. A simple mapping to oBIX would probably look something like this:
<obj is=’obix:vcalendar’> <str name=’version’ val=’2.0’/> <str name=’prodid’ val=’-//hacksw/handcal//NONSGML v1.0//EN’/> <obj is=’obix:vevent’> <abstime name=’dtstart’ val=’19970714T170000Z’/> <abstime name=’dtend val=’19970715T035959Z’/> <str name=’summary’ val=’Bastille Day Party’/> </obj> </obj> Some of the rules I used to create this mapping: 1) Map from upper case to lower case (which matches our oBIX
naming conventions). xCAL actually does an exact upper-to-lower case
transform which is fine, although I’d probably suggest we go with a camel
case transfer (dashes transform to upper case word breaks) to stay consistent
with oBIX. Either way should be easy to implement bi-directional
conversions during transformations. 2) Object types map to contracts – for example
VCALENDAR, VEVENT, VTIMEZONE. These are the things defined by the BEGIN and END
tags. They seem to naturally map to contracts. 3) Properties are mapped to objects where the name attribute
matches the iCalendar property name (with a case conversion). My thoughts
on properties are that they would not be contracts themselves (unless they had
a substructure like an “rrule”) – but rather defined as
children objects of the vevent, vtimezone, etc objects. Since most
properties are options, we would probably define the prototypes to default to
null. If we went with those basic rules, then a large chunk of the effort
is in mapping each iCalendar property type to its oBIX object. The three
property types which we’ll need to think about are date-time, date, and
time. On the surface a data-time is clearly an abstime – however there
are special rules in iCalendar about timezone handling. We omitted a date
and time primitive in oBIX – mostly because they are only useful for
scheduling. However now that we will be tackling scheduling, we might
want to consider making data and time new first class value types. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]