Hi,
As discussed on Friday, I have added some material for thinking on Jira #124.
Some thoughts following Friday's conf call:
The interval as defined by dtStart and Duration is fine, and it is worth using it for 2 other use cases:
1/ A zero-length duration called event in many automation fields, or milestone in project planning.
If we conclude on the fact that 0 is a valid duration, the case is quite easy to solve.
Maybe a duration of 0 should impact the inheritance mechanism. Maybe blocking it (if an interval is of duration 0, the duration can not overriden to something else than 0 by a parent gluon), but allowing to define a 0 duration in a gluon that would apply to children intervals not having the duration defined.
About dtEnd in this case: dtEnd = dtStart+Duration so with a 0 duration interval dtEnd is "simply" equal to dtSart.
2/ Toby's lime, is with no doubt an interval defined by a dtStart and a duration except that the duration will be known later. It is for real an interval, should be defined the same way than any other, I would not advise to create another type of element for this.
With the hypothesis that the duration can not be optional, the first issue is how to express the Duration. I would tend to say that we should make the Duration not optional but nillable, the Duration element being always present, but with no value in the lime case.
Another option would be to pick a particular value, for example, the minimum value of xs:DateTime or the maximum value. Picking the min value would probably be ok (easily testable and no side effect in the future); picking the max value may introduce yet another y2k series of bugs ?
The second issue introduced by the lime concept is that it is the first one where there is a particular need of identification of the interval when the further notice comes with the duration. First being able to correlate this interval coming with a duration, in addition to specifying in a very clear manner what should be the dtStart and duration in the further notice message.
Example:
First message with a dtStart1 a no duration (a lime)
Then a second message describing the same interval with a dtStart2 and a duration value:
- Should dtStart1 = dtStart2 and the duration equal to the actual duration the requester wants or wanted (maybe dtStart1 is in the past and the interval is already started, maybe it is in the future and the interval is not yet started).
- Could dtStart2 be arbitrary and duration be processed according to dtStart2, or to the timestamp of the 2nd message. Maybe some other options are possible.
This second option would allow someone to send a further notice with a duration of 0 meaning "stop now".
Ideas ?
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 : wtcox@coxsoftwarearchitects.com [mailto:wtcox@coxsoftwarearchitects.com]
Envoyé : vendredi 28 janvier 2011 19:54
À : Bartell,Bruce
Cc : Toby.Considine@gmail.com; ws-calendar@lists.oasis-open.org
Objet : RE: [ws-calendar] Short Fuse - Events and No Duration
Bruce -
Thanks. I'll deal with it today (and decide which way to go).
bill
-------- Original Message --------
Subject: RE: [ws-calendar] Short Fuse - Events and No Duration
From: "Bartell, Bruce" <bbartell@xtensible.net>
Date: Fri, January 28, 2011 1:09 pm
To: "Bartell, Bruce" <bbartell@xtensible.net>,
<Toby.Considine@gmail.com>;, <ws-calendar@lists.oasis-open.org>The Issue for this is #124. I re-opened with a question/comment what to do with end date. If we want to open a separate issue for the use case submitted by Benoit, that’s fine.
From: Bartell, Bruce [mailto:bbartell@xtensible.net]
Sent: Thursday, January 27, 2011 10:51 AM
To: Toby.Considine@gmail.com; ws-calendar@lists.oasis-open.org
Subject: RE: [ws-calendar] Short Fuse - Events and No Duration
I believe Mike called this a State Event in the last call I attended.
From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
Sent: Thursday, January 27, 2011 9:58 AM
To: ws-calendar@lists.oasis-open.org
Subject: [ws-calendar] Short Fuse - Events and No Duration
There is a desire to have WS-Calendar communicate “From this point in time, X, until further notice”
This might be “Price is now $3 until further notice”
This might be “Run until I stop you”
This might be…
Let’s call this a lime.
Within the v* Objects this would be handled by having a communication with a start time an no duration.
We have many conformance rules that say “An interval always has a duration”…
A Lime breaks conformance.
We have inheritance rules that suggest that anything that is missing, can be over-ridden.
It is likely that we do not want to override limes.
We could put a duration of Zero to block inheritance, but that would appear contrary to the stated goal of defining an open-ended duration
I think that Limes should *not* have durations.
There is no reason why a Lime cannot be part of a sequence, and several reasons to allow it.
This means that Limes do support temporal relations
I think this means that the Lime is not an interval. This leads to “A Sequence consists of one or more [Intervals or Limes] and 0 or more Gluons.
A Lime can inherit a dtStart.
A Lime cannot inherit a duration.
A Lime can inherit an Attach.
I think a Lime can inherit Performance attributes.
So what is a Lime?
Can we use any existing objects? The only one that *Sounds* likely is the valarm, but I think this is pushing the valarm too far (see valarm below)
To me, it looks like an interval that is constrained from using Duration, but is Interval –like in all other ways. This suggests that we have yac, and that component is known as:
Is a Lime an EVENT? Possibly too over-ridden. “A DR Event starts at 2:00 and goes for the next two hours” would then have to be a sequence consisting of an EVENT and an Interval, or instead have the rule, “Use Intervals for events, but not EVENTs.” That feels wrong.
Is a Lime an Alarm? I let this mistake happen in oBIX, and I don’t want to do this again. THe Semantics of receiving an alarm that everything is normal is bad.
Is a Lime a NOTICE? Price Notice sounds good. Event Notice sounds good.
<xs:complexType name="WsCalendarNoticeType" mixed="false">
<xs:complexContent mixed="false">
<xs:extension base="xcal:BaseComponentType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="x-wscalendar-notice" type="xcal:WsCalendarNoticeType" substitutionGroup="xcal:baseComponent"/>
Conformance: A Notice SHALL NOT include a Duration.
Other proposals? Objections?
tc
Description: A "VALARM" calendar component is a grouping of
component properties that is a reminder or alarm for an event or ato-do. For example, it may be used to define a reminder for apending event or an overdue to-do.The "VALARM" calendar component MUST include the "ACTION" and"TRIGGER" properties. The "ACTION" property further constrainsthe "VALARM" calendar component in the following ways:When the action is "AUDIO", the alarm can also include one andonly one "ATTACH" property, which MUST point to a sound resource,which is rendered when the alarm is triggered.When the action is "DISPLAY", the alarm MUST also include a"DESCRIPTION" property, which contains the text to be displayedwhen the alarm is triggered.When the action is "EMAIL", the alarm MUST include a "DESCRIPTION"property, which contains the text to be used as the message body,a "SUMMARY" property, which contains the text to be used as themessage subject, and one or more "ATTENDEE" properties, whichcontain the email address of attendees to receive the message. Itcan also include one or more "ATTACH" properties, which areintended to be sent as message attachments. When the alarm istriggered, the email message is sent.The "VALARM" calendar component MUST only appear within either a"VEVENT" or "VTODO" calendar component. "VALARM" calendarcomponents cannot be nested. Multiple mutually independent"VALARM" calendar components can be specified for a single"VEVENT" or "VTODO" calendar component.The "TRIGGER" property specifies when the alarm will be triggered.The "TRIGGER" property specifies a duration prior to the start ofan event or a to-do. The "TRIGGER" edge may be explicitly set tobe relative to the "START" or "END" of the event or to-do with the"RELATED" parameter of the "TRIGGER" property. The "TRIGGER"property value type can alternatively be set to an absolutecalendar date with UTC time.In an alarm set to trigger on the "START" of an event or to-do,the "DTSTART" property MUST be present in the associated event orto-do. In an alarm in a "VEVENT" calendar component set totrigger on the "END" of the event, either the "DTEND" propertyMUST be present, or the "DTSTART" and "DURATION" properties MUSTboth be present. In an alarm in a "VTODO" calendar component setto trigger on the "END" of the to-do, either the "DUE" propertyMUST be present, or the "DTSTART" and "DURATION" properties MUSTboth be present.The alarm can be defined such that it triggers repeatedly. Adefinition of an alarm with a repeating trigger MUST include boththe "DURATION" and "REPEAT" properties. The "DURATION" propertyspecifies the delay period, after which the alarm will repeat.The "REPEAT" property specifies the number of additionalrepetitions that the alarm will be triggered. This repetitioncount is in addition to the initial triggering of the alarm. Bothof these properties MUST be present in order to specify arepeating alarm. If one of these two properties is absent, thenthe alarm will not repeat beyond the initial trigger.The "ACTION" property is used within the "VALARM" calendarcomponent to specify the type of action invoked when the alarm istriggered. The "VALARM" properties provide enough information fora specific action to be invoked. It is typically theresponsibility of a "Calendar User Agent" (CUA) to deliver thealarm in the specified fashion. An "ACTION" property value ofAUDIO specifies an alarm that causes a sound to be played to alertthe user; DISPLAY specifies an alarm that causes a text message tobe displayed to the user; and EMAIL specifies an alarm that causesan electronic email message to be delivered to one or more emailaddresses.In an AUDIO alarm, if the optional "ATTACH" property is included,it MUST specify an audio sound resource. The intention is thatthe sound will be played as the alarm effect. If an "ATTACH"property is specified that does not refer to a sound resource, orif the specified sound resource cannot be rendered (because itsformat is unsupported, or because it cannot be retrieved), thenthe CUA or other entity responsible for playing the sound maychoose a fallback action, such as playing a built-in defaultsound, or playing no sound at all.In a DISPLAY alarm, the intended alarm effect is for the textvalue of the "DESCRIPTION" property to be displayed to the user.In an EMAIL alarm, the intended alarm effect is for an emailmessage to be composed and delivered to all the addressesspecified by the "ATTENDEE" properties in the "VALARM" calendarcomponent. The "DESCRIPTION" property of the "VALARM" calendarcomponent MUST be used as the body text of the message, and the"SUMMARY" property MUST be used as the subject text. Any "ATTACH"properties in the "VALARM" calendar component SHOULD be sent asattachments to the message.Note: Implementations should carefully consider whether theyaccept alarm components from untrusted sources, e.g., whenimporting calendar objects from external sources. Onereasonable policy is to always ignore alarm components that thecalendar user has not set herself, or at least ask forconfirmation in such a case.
“It is difficult to get a man to understand something, when his salary depends upon his not understanding it” -- Upton Sinclair.
Toby Considine
TC9, IncOASIS Technical Advisory Board
TC Chair: oBIX & WS-CalendarTC Editor: EMIX, EnergyInterop
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee
Email: Toby.Considine@gmail.com
Phone: (919)619-2104
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php