OASIS Open Mailing List Archives  ·  All Lists  ·  ws-calendar  ·  2011-05

ws-calendar — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Events and State Changes


After some conversation... A vevent may be the entity to define a change of state - rfc5545 has this text: For cases where a VEVENT calendar component specifies a DTSTART property with a DATE-TIME value type but no DTEND property, the event ends on the same calendar date and time of day specified by the DTSTART property. which essentially means a vevent with no end but a datetime start marks an instant in time. The event could mean (in context) change your state from A to B Note that a vevent with a DATE only start and no end is an all day event - NOT a single instant in time. On 05/16/2011 10:12 AM, Mike Douglass wrote: [email protected] type= cite > Take a look at https://tools.ietf.org/html/draft-daboo-valarm-extensions-03 On 05/16/2011 09:00 AM, Toby Considine wrote: [email protected] type= cite > I spent most of yesterday working with Mike’s new, very much improved schemas. You will see that for all objects, they are no cleaner. Last week, I raised the issue of using the proper object for the proper purpose. We had fallen into using a “0 duration Interval” to announce state changes, as if the rest ofg the vobjects never existed. Of course, the <xcal:vevent xmlns:xs= http://www.w3.org/2001/XMLSchema-instance xmlns:xcal= urn:ietf:params:xml:ns:icalendar-2.0 >                 <xcal:properties> <xcal:uid>                                                 <xcal:text>a57e3fc7-2b27-4b70-96b0-b7ff6f4056e1</xcal:text> </xcal:uid> <xcal:dtstart> <xcal:parameters> <xcal:tzid> <xcal:text>America/New_York</xcal:text> </xcal:tzid> </xcal:parameters> <xcal:date-time>2011-05-28T16:15:00</xcal:date-time> </xcal:dtstart>                 </xcal:properties>                 <xcal:components/> </xcal:vevent> ICalendar already has the vtodo (which we initially modeled the interval on) which is driven by the End Date, that is, if it has one of the three (Duration, Start, End), it has End <xcal:vtodo xmlns:xs= http://www.w3.org/2001/XMLSchema-instance xmlns:xcal= urn:ietf:params:xml:ns:icalendar-2.0 >                 <xcal:properties> <xcal:uid>                                                 <xcal:text>30ca1940-a79b-4d22-841d-751e81fb99e8</xcal:text> </xcal:uid> <xcal:dtend> <xcal:parameters> <xcal:tzid> <xcal:text>America/New_York</xcal:text> </xcal:tzid> </xcal:parameters>                                                 <xcal:date-time>2011-05-28T16:15:00</xcal:date-time> </xcal:dtend>                 </xcal:properties>                 <xcal:components/> </xcal:vtodo> ICalendar already has the valarm which is driven by the Start Date, that is, if it has one of the three (Duration, Start, End), it has Start <xcal:valarm xmlns:xs= http://www.w3.org/2001/XMLSchema-instance xmlns:xcal= urn:ietf:params:xml:ns:icalendar-2.0 >                 <xcal:properties> <xcal:uid>                                                 <xcal:text>c437be23-d744-498d-b0f2-5ea888f154f5</xcal:text> </xcal:uid> <xcal:dtstart> <xcal:parameters> <xcal:tzid> <xcal:text>America/New_York</xcal:text> </xcal:tzid> </xcal:parameters>                                                 <xcal:date-time>2011-05-28T16:15:00</xcal:date-time> </xcal:dtstart>                 </xcal:properties> </xcal:valarm> I see no reason why we shouldn’t use the valarm for state changes and for price announcement s with indefinite changes… Valarm has the added charm of already including concepts as “when this happens, start playing selected music 5 minutes in advance…” tc “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. Toby Considine TC9, Inc 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 Spam Not spam Forget previous vote -- Mike Douglass [email protected] Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 Spam Not spam Forget previous vote -- Mike Douglass [email protected] Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]