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:
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:
Phone: (919)619-2104
http://www.tcnine.com/
blog: www.NewDaedalus.com
Spam
Not
spam
Forget
previous vote
--
Mike Douglass
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
Senior Systems Programmer Communication & Collaboration Technologies
518 276 6780(voice) 2809 (fax)
Rensselaer Polytechnic Institute 110 8th Street,
Troy, NY 12180
