W3C home > Mailing lists > Public > www-rdf-calendar@w3.org > September 2001

iCal - SkiCal - iptel

From: Greg FitzPatrick <greg@metamatrix.se>
Date: Fri, 7 Sep 2001 13:59:57 +0200
To: <www-rdf-calendar@w3.org>
Cc: <ietf-calendar@imc.org>, <iptel@lists.bell-labs.com>
This was sent to us off-list but since the point made is quite relevant not
only to SkiCal but to the iptel discussions that I will cite the question
and answer it here.

:    I suppose it's a little late for major structural changes :) , but I
:was wondering why you don't use some sort of VEVENT reference pointing
:to a separate VEVENT describing the time (and other) details of the

The reference here is to the proposed SkiCal mechanism for qualifying
particular aspects of an event (or as we say SkiSource).

For example there might be a scheduled event:

SUMMARY:Audition schedules for Commedy Hour

With SkiCal you can make statements about particpants in the event as


and it might be expedient to include the individual times for the three
participants which you can do in the proposed revision of SkiCal as follows:


The opref value points to an OPENTIMES declaration that is made on the
OPTIMES property

OPTIMES:<optimeset ID="slot-1"><OPTERM range="20010907//20010907">
 <OPHOURS range="120000/124500"/></OPTERM></optimeset>
OPTIMES:<optimeset ID="slot-2"><OPTERM range="20010907//20010907">
 <OPHOURS range="130000/134500"/></OPTERM></optimeset>
OPTIMES:<optimeset ID="slot-3"><OPTERM range="20010907//20010907">
 <OPHOURS range="140000/144500"/></OPTERM></optimeset>

(actually you don't have to repeat the OPTERM on every slot - it can be
IDREF:ed as well.

When parsed this would result in something like this

***  Audition schedules for Comedy Hour - September 7th - 2001 ***

1200 - 1245 Alice
1300 - 1345 Bob
1400 - 1445 Carol

the rest of the question reads...

>  It seems this would be more consistent, from an engineering
>point of view.  Although it would require a little more text, recall
>that VEVENTs don't need to be very large at all - having a UID, start,
>and end time would be sufficient for most purposes.  And having the
>information as a separate VEVENT would allow consumers of the data to
>choose portions of an event that they're interested in for incorporation
>in their calendar (for example, some users might only be interested in
>bar opening & closing times for an event, and not the main show ;)

Which of course makes good sense, but still necessitates a new property
parameter that accomplishes the reference to the appropriate VEVENTs.

The existing RELATED-TO 2445 property cannot of course distinguish
relationships to particular aspects of a calendar object.

The advantages of VEVENTS for this purpose are evident.  Among other
versioning comes immediately to mind.  And of course for SkiCal users this
would give a choice of using DTSTART and its related properties or DTOPEN.


Of course this also points to possibilities for the IPTEL problems, since
DTOPEN pointing to an optimeset is probably a much better solution for the
IPTEL use-domain. (IMHO)

Received on Friday, 7 September 2001 07:59:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:10 UTC