Perspective on inheritance vs Inclusion of vCalendar (EMIX vs EI)

Emix is a pure information model. It deliberately is agnostic about mechanisms and communication. Emix prices and products can be directly posted to existing schedules and calendars that are standards compliant, should one want to use any ITIP-compliant protocol , including SMTP, CalDAV, REST, or SOAP. EMIX information structures can be carried directly by anything.

EI is itself an interaction pattern, and one that is not compliant with anything that is ITIP compatible. This means that EI gets no benefit from being pushed through an ITiP strainer. Carrying a vcalendar object or objects inside an EI message does not limit EI transport in anyway. This allows more flexibility on decoration of the larger object, and more flexibility in the number of vcalendar objects that might be inside a single information exchange.

If one of the end points happens to want to store the schedules inside a standards-based calendar server, they clearly can do that. They would strip away the transaction headers, required by EI, and store the vcalendar objects, complete with intervals and gluons, inside the calendar store. No functionality is lost there.

In the meantime, Ed’s proposal (made earlier by Bruce, but it took a while for me to understand it) allows the e-commerce patterns that we want for Energy Interop to predominate.

Its already a done deal, but I like to back into things from several directions.

“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

energyinterop message