[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix] We need to get moving on ICALENDAR Binding
The current idea is to define a subset of ICalendar used by most people and define a clean mapping to the oBIX model.
The translation b/w ICalendar and oBIX would be machine processable, so client/servers could support both.
From: Considine, Toby
(Campus Services IT) [mailto:Toby.Considine@unc.edu]
I found a few similar efforts today.
Everywhere, folks are dancing around solving this problem. Bob is Right, we need to be based on ICALENDAR, but what does this mean?
I have gotten several suggestions for shims, or embedding XSLT in WS-*, or… but I get no answers, only chewing gum and bailing wire. ICALENDAR allows all sorts of schedules, ranging from single events to 3rd Tuesday of the month, even exceptions for months that have a 5th Tuesday. It also understands time zones, while enabling you to schedule a single event that will occur at 8:30 AM local time at every office around the world. It is reasonably flexible and complete. On the other side, we have ad hoc formats that might have a beginning time and a duration only. BPEL does not have, AFAIK, any good way to handle the repeating formats, the indefinite formats, etc. I have found no actual standard that is anything like it in XML. I have even had some feelers out to W3C folks and the silence is, well, silent.
We all know the natural and easy use case for oBIX that looks like “Conference room scheduled for 17 people at 3:00, tell building systems to establish temperature/humidity/warm up equipment by 3:00. Ventilation adequate for 17 people and continue to do so for the full hour”.
Grid-based Demand/Response *could* work on BPEL or something like BPEL, but customers are not necessarily buying in to these transactions. It seems somehow less elegant.
Exchange or Work Orders (OSCRE) and exchange of Medical Appointments could use something like this.
Emergency response, especially predictions of storm events could benefit from this. I can imagine a variant of HAVE that predicts availability tomorrow based upon Maintenance Schedules.
Green Grid scenarios are easy to imagine. Would transformer reliability estimates be sent with maintenance schedules for reduced capacity?
Many of these areas of work, these domains, do share information about planned events with each other, but not as a direct control process.
Alongside the scheduling moment, there is the question of payload…
There are only two real options.
1) ICALENDAR is a full fledged XML data type, and so can get passed in its current format
2) ICALENDAR must have a standard transformation, referenced by all.
The first has a certain simplicity to it, and one could imagine easily scraping some sort of existing Calendar to add some building commands and go, as a shim.
The second feels like a better final solution, but it has another question.
A) Is the contract/behavior/event inside or alongside the ICAL. Just as an event now is inside the Schedule, I could imagine an [oBIX Contract] inside a event.
B) Does the event have a reference to an external contract, an internal link? One could imagine invoking one process to occur at 7 times, by re-using the link ID. In the grid-aware scenario, we could imagine 7 energy usage scenarios, spead over multiple schedules, and bidding alternative const proposals…
C) Calendar and other contract exist alongside each other inside some higher-order envelope.
Am I missing something?
"There are a thousand hacking at the branches of evil to one who is striking at the root." -- David Thoreau