OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-calendar message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-calendar] Events and State Changes


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


Toby Considine

Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

Facilities Technology Office
University of North Carolina
Chapel Hill, NC

  

Email: Toby.Considine@ unc.edu
Phone: (919)962-9073

http://www.oasis-open.org

blog: www.NewDaedalus.com

 

 

From: Edward Koch [mailto:ed@akuacom.com]
Sent: Monday, May 16, 2011 11:10 AM
To: Mike Douglass; ws-calendar@lists.oasis-open.org
Subject: RE: [ws-calendar] Events and State Changes

 

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]
Sent: Monday, May 16, 2011 10:27 AM
To: ws-calendar@lists.oasis-open.org
Subject: Re: [ws-calendar] 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:

Take a look at

https://tools.ietf.org/html/draft-daboo-valarm-extensions-03

On 05/16/2011 09:00 AM, Toby Considine wrote:

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: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 



-- 
 
Mike Douglass                           douglm@rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180



-- 
 
Mike Douglass                           douglm@rpi.edu
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] | [List Home]