iCal - SkiCal - iptel

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
:property?

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:

BEGIN:VCALENDAR
...
BEGIN:VEVENT
ORGANIZER:MAILTO:greg@skical.org
DTSTART:20010907T113000
DTEND:20010907T160000
...
SUMMARY:Audition schedules for Commedy Hour
...
END:VEVENT
END:VCALENDAR

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

...
SKiCal-PEOPLE;SKIROLE="Judge":Tom
SKiCal-PEOPLE;SKIROLE="Auditioning":Alice
SKiCal-PEOPLE;SKIROLE="Auditioning":Bob
SKiCal-PEOPLE;SKIROLE="Auditioning":Carol


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:

SKiCal-PEOPLE;SKIROLE="Judge":Tom
SKiCal-PEOPLE;SKIROLE="Auditioning";OPREF="slot-1":Alice
SKiCal-PEOPLE;SKIROLE="Auditioning";OPREF="slot-2":Bob
SKiCal-PEOPLE;SKIROLE="Auditioning";OPREF="slot-3":Carol

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.

http://www.skical.org/skical20010905.html#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)

Greg

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