Re: More Work on iCalendar RDF Schema

> I think I'm beginning to see a way through. My strong feeling is that
> date-times need to be typed objects, and not just strings. This is
> backed up by the DAML version of xml datatypes in RDF by Dan C.
> However, unlike iCalendar rfc 2445, xml datatypes use UTC offsets for
> timezones. Maybe what we could do is use objects for date-times but
> allow UTC offsets to conform to xml datatypes. This would mean a
> difference between icalendar in RDF and icalendar RFC 2445 though; and
> I'm sure there are good reasons for the decision not to allow UTC
offset
> as part of the string (although it does appear as a property of a
> date-time...). I've yet to finish going through the Calsch mailing
list
> archives - please forgive my ignorance.
>
> So this may seem like the worst of both worlds, since you get an
object
> and not a simple string, but without the precision of a timezone
> definition object. But for many people it would be sufficient and it
> conforms with standard RDF practice and xml datatypes.
>
> what do you reckon?

    Looking at a date-time value by itself, it doesn't need a full
timezone specification; it only needs an offset (after all, one
individual time instant cannot span a DST change).  The reason we use
the fuller concept of references to timezone objects in iCalendar is
that "a time isn't always just one time".
    In iCalendar, the DTSTART is used to specify the beginning of a
RRULE.  However, the RRULE doesn't need to fully qualify all succeeding
instances; for example, an RRULE may only say something like "repeat
every week", as in:
    RRULE:FREQ=WEEKLY

    Since the RRULE doesn't mention anything about the other details of
the succeeding recurrences, these elements are "inherited" from the
DTSTART.  The elements include, to use the WEEKLY example above, such
things as which day of the week each recurrence is on, and (the core of
the issue here discussed) the start time.
    As the time component (among other components) of the DTSTART is
applied not just to that one instance of the event, but can potentially
be applied to ALL of them, it is not sufficient to simply give an offset
from UTC for the DTSTART.

    Some might argue that this overloading of the date-time type isn't
really called for and there are better ways of expressing it.  Probably
you could find some means of communicating the intent of iCalendar while
keeping the date-time type restricted to "only" a UTC offset, rather
than some timezone entity reference (said reference could, for example,
be added to the rdf version of RRULE instead, although you'd have to be
careful if you wanted to maintain the implied iCalendar restriction that
all the recurrences (including the one specified by the DTSTART) are in
the same timezone).

    Graham

Received on Friday, 22 June 2001 14:29:32 UTC