OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

obix-xml message

[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]