ws-calendar — archive

Short Fuse - Events and No Duration

From: Bruce Bartell <[email protected]>
To: [email protected]
Date: Thu, 27 Jan 2011 15:54:00 -0000

I believe Mike called this a State Event in the last call I attended. Bruce Bartell Xtensible Solutions Mobile : +1.321.258.6500 [email protected] www.xtensible.net From: Toby Considine [mailto:[email protected]] On Behalf Of Toby Considine Sent: Thursday, January 27, 2011 9:58 AM To: [email protected] 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 a to-do. For example, it may be used to define a reminder for a pending event or an overdue to-do. The "VALARM" calendar component MUST include the "ACTION" and "TRIGGER" properties. The "ACTION" property further constrains the "VALARM" calendar component in the following ways: When the action is "AUDIO", the alarm can also include one and only 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 displayed when 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 the message subject, and one or more "ATTENDEE" properties, which contain the email address of attendees to receive the message. It can also include one or more "ATTACH" properties, which are intended to be sent as message attachments. When the alarm is triggered, the email message is sent. The "VALARM" calendar component MUST only appear within either a "VEVENT" or "VTODO" calendar component. "VALARM" calendar components 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 of an event or a to-do. The "TRIGGER" edge may be explicitly set to be 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 absolute calendar 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 or to-do. In an alarm in a "VEVENT" calendar component set to trigger on the "END" of the event, either the "DTEND" property MUST be present, or the "DTSTART" and "DURATION" properties MUST both be present. In an alarm in a "VTODO" calendar component set to trigger on the "END" of the to-do, either the "DUE" property MUST be present, or the "DTSTART" and "DURATION" properties MUST both be present. The alarm can be defined such that it triggers repeatedly. A definition of an alarm with a repeating trigger MUST include both the "DURATION" and "REPEAT" properties. The "DURATION" property specifies the delay period, after which the alarm will repeat. The "REPEAT" property specifies the number of additional repetitions that the alarm will be triggered. This repetition count is in addition to the initial triggering of the alarm. Both of these properties MUST be present in order to specify a repeating alarm. If one of these two properties is absent, then the alarm will not repeat beyond the initial trigger. The "ACTION" property is used within the "VALARM" calendar component to specify the type of action invoked when the alarm is triggered. The "VALARM" properties provide enough information for a specific action to be invoked. It is typically the responsibility of a "Calendar User Agent" (CUA) to deliver the alarm in the specified fashion. An "ACTION" property value of AUDIO specifies an alarm that causes a sound to be played to alert the user; DISPLAY specifies an alarm that causes a text message to be displayed to the user; and EMAIL specifies an alarm that causes an electronic email message to be delivered to one or more email addresses. In an AUDIO alarm, if the optional "ATTACH" property is included, it MUST specify an audio sound resource. The intention is that the sound will be played as the alarm effect. If an "ATTACH" property is specified that does not refer to a sound resource, or if the specified sound resource cannot be rendered (because its format is unsupported, or because it cannot be retrieved), then the CUA or other entity responsible for playing the sound may choose a fallback action, such as playing a built-in default sound, or playing no sound at all. In a DISPLAY alarm, the intended alarm effect is for the text value of the "DESCRIPTION" property to be displayed to the user. In an EMAIL alarm, the intended alarm effect is for an email message to be composed and delivered to all the addresses specified by the "ATTENDEE" properties in the "VALARM" calendar component. The "DESCRIPTION" property of the "VALARM" calendar component 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 as attachments to the message. Note: Implementations should carefully consider whether they accept alarm components from untrusted sources, e.g., when importing calendar objects from external sources. One reasonable policy is to always ignore alarm components that the calendar user has not set herself, or at least ask for confirmation 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, Inc OASIS Technical Advisory Board TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Email: [email protected] Phone: (919)619-2104 http://www.tcnine.com/ blog: www.NewDaedalus.com