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: RE: [TypeDisc] EventState

Title: [TypeDisc] EventState



I’m certainly not against adding more attributes especially if it is needed to insure that we can send the right type and range of information.  The working assumption was that as some of the data types such as price were more richly defined that there would naturally be more attributes added to the data and I always assumed we would make the representations richer than they currently are. That being said there will always be a tradeoff between the flexibility vs complexity issue and I would hesitate to make a blanket statement that we will make the data as self descriptive as possible.  I will definitely have to object if we start straying into meta-schemas. Every time we make a change of this nature we should ask ourselves the following questions:


-        What is the effect of adding more attributes or complexity to the data structures for the lowest end devices that might consume these messages.  BTW – I’d like to avoid a debate about the cost and power of cpus because that’s not the issue.


-        What is the effect of adding more attributes or complexity to the data types on the ease of creating simple rules that can be defined by the end user to translate the information into actionable load control strategies. One might be tempted to assume that you can deal with complexities with the appropriate SW tools, but if we aren’t careful then we might find that a somewhat sophisticated tool with a rich user interface is required.


Again, I’m not married to the current schema in this regard and I think that we should add whatever attributes we think are necessary.  I just want to do it with the proper considerations.



-ed koch



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:


        Value: 3.50

        timeOffset: 900

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


        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?




<<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



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..

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