RE: [energyinterop] [TypeDisc] EventState

HI David,

My only comment is basically naming convention: eventInfoInstance, I believe, should not be in the schema. Usually, an instance is an instantiation of an object and thus this naming conventions (just like certificates) causes a little confusion for OO geeks (like me).

With kind regards,

********************************

Michel Kohanim, C.E.O

Universal Devices, Inc.

(p) 818.631.0333

(f) 818.436.0702

http://www.universal-devices.com

********************************

From: Wilson, David C (St. Paul) [mailto:DavidCWilson@trane.com]
Sent: Wednesday, February 03, 2010 2:54 PM
To: energyinterop@lists.oasis-open.org
Subject: [energyinterop] [TypeDisc] EventState

I think the EventState type provides a good example of the flexibility/complexity challenge that I would like to highlight. As you’ll notice from either the XSD or PNG attached, the lowest level of the SmartClientDREventData provides a list of decimal values & time offset pairs. The type of theses values is designated in the string value eventInfoName.

eventInfoName Documentation

--------------------------------------

This is the name for the Event Info Type that was given by the Utility when the DR program was first established. It is analogous to a variable name. By having a name it allows multiple instances of the same type (i.e. PRICE_ABSOLUTE) to be sent in the Event Instance.

--------------------------------------

For example:

EventInfoValue:

Value: 3.50

timeOffset: 900

Compare this approach with a more strongly/structured typed approach:

EventInfoValue:

Price: 3.50

Currency: USD

SecondsOffset: 900

LoadTarget: 250

As a potential consumer of this information, I want the types of the values to be defined inside the interface (at least to the level of Price, Load, Consumption, Reduction vs Absolute) while the business rules can be a priori defined in the program/contract.

Was the common program in OpenADR definition the only factor contributing to the weaker/flatter type approach? What other factors drove this design?

Do you agree or disagree with the general trend to add more meaning to the elements for the EnergyInterop specification?

Regards,

Dave

<<EventInfo.xsd>> <<EventState.png>>

David Wilson

Enterprise Solutions Portfolio Manager

Trane Commercial Systems

Ingersoll Rand

Office: +1.651.407.4168

Mobile: +1.612.741.2759

Email: davidcwilson@trane.com

www.trane.com

The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachment..

energyinterop message