[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Baby and Bathwater
|
I’m interested in applying ws-calendar intervals
in a very specific use case which is slightly different than what I see below.: Conference session 1:00 – 3:00 John Smith talks first for
30 min when the session starts (i.e. 1:00) Bill Todd talks for 30
min when John Smith finishes Henry Jud talks for 1
hour when Bill Todd finishes Thus I want to create a sequence of intervals
that partition a higher level interval. This seems like a very common usage
pattern. Thanks, -ed koch From: Considine, Toby
(Campus Services IT) [mailto:Toby.Considine@unc.edu] In
WS-Calendar, we (or maybe just I) have been tightly focused on the Interval and
the Gluon. Last weeks’ conversation on Duration, Start, and End focused this.
For Intervals to be re-locatable, to act as “schedule sub-routines”, they *must* be duration based. That is what drove
the creation of the temporal relations. In
iCalendar, there are a number of objects. In carton form, the primary different
between them is that they have different conformance rules around that troika. Events
have beginnings and ends Todos
are driven by completion deadlines, and driven by end. Free-Busy
is an irregular collection (bag) of little-I intervals Availability
is a regular collection (bag) of repeating little-I intervals Alarms
are scheduled moments in time, usually defined by their relation to another
component, and without duration and have (IIANM) only a start Journals
are historical moments in time (Does even the Outlook journal function use a
Journal?) and have (IIANM) only a start Perhaps
the real issue is that we are focusing over-much on the interval, a special
purpose, deliberately degenerate form of the vComponent. For
example, we spent a week discussing publishing of notices, and the semantics of
expressing an notice as an interval. Throughut that conversation, we ignored
the iCalendar Alarm, and carefully recreated the semantics of the Alarm as a
special case in Intervals. I
had forgotten that all of the icalendar components are potentially part of
ws-calendar conversations. An
exchange with Mike this week made this abundantly clear to me. We were
discussing the use of a Sequence as a subroutine for a fictitious caterer. (Quote
from Mike) As I understand it intervals express something to be
done (or needed). An example was catering which might have Interval1 - travel to - fixed duration Interval2 - setup - fixed Interval3 - the event - variable duration Interval4 - tear-down - fixed Interval5 - travel from - fixed duration A gluon effectively fixes this in time by giving
interval3 a start and duration. One question was - why is an interval not just a task
(vtodo). I sort of persuaded myself that the semantics (and some rules) are
sufficiently different that using a vtodo would confuse things. A question: how do we see this interacting with
existing installations? Once these are fixed in time I guess a product might
be a set of vtodos. What are the rules for converting from interval to
vtodo? This would be important for those who would like to use these
constructs/concepts and want to allow the results to be displayed and handled
by existing clients. (end
quote) (reply) An Interval is a unit of time, and can be bound to
service delivery. An Unscheduled Interval has no specified date and time. A
Scheduled Interval has a specified start date and time. Intervals can legally
contain all elements properties as defined in [RFC5545]. For convenience, the
elements essential to coordinating service operations using Intervals are listed
in Table 3-1. An Interval is part of a Sequence. An entire Sequence
can be scheduled by scheduling a single Interval in a Sequence. A single
Sequence can be scheduled multiple times through repeated reference by
different Gluons. For this reason, of the three primary temporal elements
(dtStart, dtEnd, and Duration) in a Component, the Duration has primacy in
Intervals. Within a Sequence, a maximum of a single Interval MAY have a dtStart
or a dtEnd. I think that an entirely reasonable application would
create vtodos, or perhaps even vevents from each Interval as a Sequence is
transacted. Another entirely reasonable Application might just add information
in place, or even re-name them with the same GUID. Such activities are
interesting, but out of scope of the Spec. (end
reply) Is
this the real answer to the dtatart/dtend/duration conformance issues? tc "If
something is not worth doing, it`s not worth doing well"
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]