[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: We need to get moving on ICALENDAR Binding
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]