OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Events and Status and Cross-talk


Posting directly because it cuts across several issues and I want it out of the Jira noise.

 

We have some new getting-close to precise descriptions of Events for us in Requests. In particular, there are Jira Issues suggesting that either party (VEN or VTN) might ask its event-oritented counter-party (VTN or VEN) what events does it know about. This is then refined to include “Only Active Events”  or ”Only Pending Events” or all.

 

Active: active is defined by the period of time specified by the active period. During this time period eventStatus will also be active

Pending: pending is the period of time before the active period starts as specified by the active period interval.

 

We have similar but not identical EventStatus, whose enumerated values are:

 

None - No event pending

Far - event pending in the far future. The exact definition of how far in the future this refers is dependent upon the market context, but typically means the next day.

Near - event pending in the near future. The exact definition of how near in the future the pending event is active is dependent on the market context

Active - The event has been initiated and is currently active.

Completed - The event has completed.

Cancelled - The event has been canceled.

 

The only use of these currently is to pass exactly one in the Event Descriptor

 

If we assume that Active is the identical in the two lists, and Pending embraces Far and Near, then we have a problem of validity.

 

If the VTN places a message for pick-up, and marks an even as “Near”, and the VTN doesn’t pick it up for 20 minutes, is the Event now invalid?

 

If this is temporary information, should the EventStatus be in the Event instead of the Descriptor?

 

Are describing the same or two different things?

 

Should a RequestEvents be able to request Cancelled, or Completed, or Far events?

 

The current Request Payloads optionally include an Interval; in their absence, the interval is “this instant”. This allows one to ask for Events Active Now, or Active in the next 24 hours, or Active in any period in the past. Does this replace the need for some of these statuses?

 

If the Request is for Pending and the Interval is the next 24 hours, is the request for

a)       any “Events not currently active but that will begin in the next 24 hours

or

b)      Any events that are still pending as of this time tomorrow.

 

I ask because (a) is the same as “Active” with an interval of 24 hours.

 

Or we could compress Status Active Completed, Cancelled. Pending would then be defined as Active anything starting after [now] or the passed interval. This eliminates pending / far / near and gives everything precise definitions.

 

Please discuss.

 

http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-635

http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-634

http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-625

 

Why do we have this status in the Event when it can be computed.

 

Should it be included in the qualifiedEventID

http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-623

whose primary use is in the “request Event IDs” (currently requestPendingEvent which returns only IDS in 33, but will return Mod Number as well in 34)

 

 


“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

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]