Streams, Events, EventBases, and Feedback.

I have been writing definitions all day today.

The naming of some of the elements of AN event make it confusing to write about and to define. In particular, we have EventSchedule and EventSchedules, in which EventSchedules is defined as a collection of EventBases (which is not quite accurate, since it is a collection of EventBaseType-derived elements.

Now that we have Streams defined as general purpose optimized schedules, It would be useful to step back from the EventSchedule and EventSchedules Language. We also overload Signals because of the underlying the enderlying EventBase.

We have a top-level pattern for the abstract type Streams, an optimized general pattern derived from WS-Calendar Sequences.

I would like to be able to write of Signals and Feedback. At the top of an Event, we would have an Event Schedule (usually just a container for an Active Period) And Event Signals, an array of Signals. Signals are derived from the Streams type conformed as they are now.

Feedback would become one of any number of Streams based metrics coming back from the VEN to the VTN. They would have the list as of now.

EventBase, then, would go away. Its current name makes it sound as the parent type for the entire event, rather than just for a part of it.

I believe this would make the definitions considerably clearer than they are now.

“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