[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: oBIX and CABA
|
Toby....as CABA is the founding organization of oBIX, we are pleased
to hear of the continued good work with oBIX. We also hope you are able to
provide an update report to the CABA Intelligent & Integrated Buildings
Council. We have attached the agenda as other people involved with oBIX may want
to participate in this important Council meeting as a guest.
We look
forward to having you on the call.
Regards,
Ron
Zimmer
CABA
President & CEO
From: Brian Frank [mailto:bfrank@tridium.com] Sent: Thursday, October 09, 2008 11:53 AM To: Considine, Toby (Campus Services IT); obix-xml@lists.oasis-open.org Cc: obix@lists.oasis-open.org 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.
http://68.142.116.68/docs/cd/B25553_01/calendar.1012/b25488/toc.htm
http://msdn.microsoft.com/en-us/library/aa564690(EXCHG.80).aspx
http://msdn.microsoft.com/en-us/library/aa564509(EXCHG.80).aspx
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.
http://www.newdaedalus.com/articles/2008/10/3/when-do-you-want-that.html
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?
Etc.
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?
tc
"There are a thousand hacking at the branches of evil to one who is striking at the root." -- David Thoreau
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]