Hi,
As stated by Toby, we probably mistakenly focused on intervals.
My view on this was that a versatile interval definition (yet less easily validated at the XML level) would have allowed to greatly minimize the number of different elements in WS-Calendar, even with keeping the ability to map all iCal/xCal elements in a bijective way.
Few thoughts:
An interval with duration = 0 or dtStart=dtEnd is a valuable “moment in time” depending on a sequence or gluon arrangement, it should probably be easy to decide whether it is an alarm or a piece of a journal in the iCal/xCal world.
A sequence including intervals may allow these intervals to be:
- Defined by dtStart/duration or duration/dtEnd or dtSttart/dtEnd (all of them, not only one in the sequence) without the need to define the gaps between them. Gaps would remain computable.
- Defined by one scheduled interval, thus requiring the gaps to be defined to schedule all intervals of the sequence. All start/end would then be computable.
The different approaches will never satisfy all the domains we try to address. Depending on the decisions we take, not only we are closer to one domain or another, but we also push more work for the implementation of a server or a client. Depending on the cases, the low level system in term of computing capability may be the server or the client, one or the other can be the one who will have to execute something, and be comfortable in getting or being able to compute the information as it needs (dtStart or End …)
Regards
Benoît LEPEUPLE
Product Manager
ARC Informatique
2 avenue de la cristallerie - 92310 SEVRES - FRANCE
Tel: +33 1 41 14 36 00 - Mobile: +33 6 87 80 20 43
Email : b.lepeuple@arcinfo.com
De : Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
Envoyé : vendredi 13 mai 2011 15:28
À : ws-calendar@lists.oasis-open.org
Objet : [ws-calendar] Baby and Bathwater
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"
Peter Drucker
Toby Considine Chair, OASIS oBIX Technical Committee Facilities Technology Office | | Email: Toby.Considine@ unc.edu http://www.oasis-open.org blog: www.NewDaedalus.com |