[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-calendar] Events and State Changes
That was my recollection of how http://tools.oasis-open.org/issues/browse/WSCALENDAR-124
was resolved. But the resolution says it has a zero duration. Bruce Bartell Xtensible Solutions From: Considine, Toby
(Campus Services IT) [mailto:Toby.Considine@unc.edu] I think that what we were doing is
acknowledging that this is *exactly*
what a vevent with no duration, no end time has always meant, <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>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:x-wsCalendar-attach>
<xx:payload
xmlns:xx="urn:not:a:real:artifact">
<xx:units>furlongs</xx:units>
<xx:quantity>14</xx:quantity>
</xx:payload> </xcal:x-wsCalendar-attach> </xcal:properties> </xcal:vevent> An object received this way can flow not
only inside special purpose smart energy engines but through corporate and
personal calendara unchanged, and with the semantics remaining as they have for
years. It may also be leaner to have events
distinguished from intervals, which are duration-based and part of sets…. Does this meet your need, Ed? Tc (like the new cleanrer schemas?) "It is the theory
that decides what can be observed." - Albert Einstein
From: I want to make sure that as part of this
discussion we are not losing sight of one very important use case which are
intervals that have a start time, but no end time, i.e. start doing something
and do it indefinitely. How is that use case being handled? -ed koch From: Mike Douglass
[douglm@rpi.edu] After
some conversation... 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.
Take a look at 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.”
--
Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute
--
Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]