[caldeveloper-l] Reset overridden occurrences on RRULE change

[Toby Considine]

Sorry to miss this...

In smart energy negotiations, an asset must declare whether it is available for response and scheduling. Consider an office building that is turned off at night (I know, not really) and air-conditions during the day. That building is able to respond to market signals during business hours, whatever they may happen to be.

OASIS Energy Interoperation (http://docs.oasis-open.org/energyinterop/ei/v1.0/cos01/energyinterop-v1.0-cos01.pdf) defined these interactions for markets. Energy Interoperation relies on WS-Calendar which is a version of iCalendar designed for M2M service negotiations of human-centric schedules. 

For this conversation, the relevant part is opting in or opting out of the market, in other words, exchanging vAvaliability messages (or un-vailability if that is the value sent). Vavailability can be oversimplified to "exchanging bags of RRules"

 https://tools.ietf.org/html/rfc7953

The authors of rfc 7593 are well known to this forum.

While rfc 7953 provides some guidance on overlaying vavailability objects, further specification is included in Energy Interoperation (see Section 5.3.5, beginning line 1140). In the example above a long term schedule may be interrupted by a company shut-down for a week, or by special operating hours during a holiday. This is done by Optin in or opting out of the market, hence the EIOpt Service.

I hope this helps...

tc

-----Original Message-----
From: caldeveloper-l [mailto:caldeveloper-l-bounces at lists.calconnect.org] On Behalf Of Tobias Friedrich
Sent: Wednesday, February 15, 2017 7:43 AM
To: caldeveloper-l at lists.calconnect.org
Subject: [caldeveloper-l] Reset overridden occurrences on RRULE change

Hi,

I wonder if there are any rules or best practices regarding resetting existing change- and delete-exceptions along with an update of the series master event, particularly if the recurrence rule changes. Previously, we removed any EXDATE and overridden occurrence; in an alternative approach, we only preserved those exceptions whose recurrence identifier is still covered when iterating through the updated recurrence set. 

So, are there any other, more sophisticated solutions possible here, or is there even something defined in the specs that I've overlooked so far?

Tobias
_______________________________________________
caldeveloper-l mailing list
caldeveloper-l at lists.calconnect.org
http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org