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: [energyinterop] Squeezing the Message


Toby,

 

I think I can resolve all these issue for you.  Rather than try to describe what to do just give me the most recent version of the schemas and I will make the appropriate changes to the schemas and generate the appropriate conformance statements.

 

 

Thanks,

 

-ed Koch

 

 

From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
Sent: Friday, July 01, 2011 7:27 AM
To: Koch, Edward; energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Squeezing the Message

 

Well, if I were building what you propose, I would come up with

 

            <!-- 9.9 Degenerate WS-Calendar derivatives  -->

            <xs:complexType name="proposedIntervalType" mixed="false">

                        <xs:sequence>

                                    <xs:element name="uid" type="xcal:UidPropType" minOccurs="1" maxOccurs="1"/>

                                    <xs:element name="duration" type="xcal:DurationValueType" minOccurs="1" maxOccurs="1"/>

                                    <xs:element ref="eventDescriptionBase"/>

                        </xs:sequence>

            </xs:complexType>

 

I would put the Start Time as a mandatory element in the EventBase, defined  the first interval as the designated interval (already in the conformance rules) and make the processing of each Interval as simple as possible.

 

You may recall, the eventDescription hierarchy looks like:

 

EventDescriptionBaseType

                EventBaselineType

                SignalInformationBaseType

                                SignalReductionType

                                SignalPercentType

                                SignalLevelType

                                SignalPriceType

                                SignalMaxType

 

This model works fine for Signal, Baseline, and Feedback

 

One problem is that there is already another degenerate Interval defined as part of the EiEventScheduleType which looks like:

 

            <xs:sequence>

                        <xs:element name="eventActivePeriod" type="eitc:IntervalType"/>

                        <xs:element name="eventNotificationPeriod" type="eitc:IntervalType" minOccurs="1"/>

                        <xs:element name="eventRampUpPeriod" type="eitc:IntervalType" minOccurs="1"/>

                        <xs:element name="eventRecoveryPeriod" type="eitc:IntervalType" minOccurs="1"/>

            </xs:sequence>

 

Each of these requires some precise definitions not currently in the spec. Without those definitions, I have to speculate. The EiInterval was defined as follows.

 

            <xs:sequence>

                        <xs:element ref="xcal:uid" maxOccurs="1"/>

                        <xs:element ref="xcal:related-to" minOccurs="0" maxOccurs="1"/>

                        <xs:element ref="xcal:dtstart" minOccurs="0" maxOccurs="1"/>

                        <xs:element ref="xcal:duration" minOccurs="0" maxOccurs="1"/>

                        <xs:element ref="xcal:x-wsCalendar-attach" minOccurs="0" maxOccurs="1"/>

            </xs:sequence>

 

Not sure what a ramp or active or recovery with no duration means. 

 

Should these be handled as per the conformable relation processing rules we use for EventsSignals? For example: there is an implied order to the sequence of

 

                        <xs:element name="eventRampUpPeriod" type="eitc:IntervalType" minOccurs="1"/>

                        <xs:element name="eventActivePeriod" type="eitc:IntervalType"/>

                        <xs:element name="eventRecoveryPeriod" type="eitc:IntervalType" minOccurs="1"/>

 

It begs the question as to why the cardinality of ActivePeriods can be anything from 0 to infinite. Was this intended?

 

Which could be handled as a normal Sequence, and push the start date into the EventSchedule as above.

 

You stated that you wanted to lose the WS-Calendar-Attach for Signals. This is what prevents convergence of the two models. Are these ramps special in some way, or are they actually just the same as ramp intervals (and potentially SPC201) in EMIX Resources.

 

If it is just EMIX resources, we can lose the special designations – its just a sequence. This would suggest that we keep the Attach for both types of intervals.

 

Finally, what is the eventNotificationPeriod above? Is it a way of stating “You have 10 minutes before Ramp starts and this is it”. Is it a way to skip start time on the ramp? Is it an agreement for a future time, in which case, it is better handled as an Emix Term. In Terms we have:

 

MinimumNotificationDuration

Availability

NotificationSchedule (another availability)

 

As it stands, we muddled semantics in the spec on hoe the EiEventScheduleType relates to the other signals. Can anyone offer a flashlight to help me through the gloom?

 

Thanks

 

tc


"He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche


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

 

 

From: Koch, Edward [mailto:Edward.Koch@Honeywell.com]
Sent: Tuesday, June 28, 2011 5:06 PM
To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Squeezing the Message

 

Toby,

 

I haven’t seen your most recent schemas, but if you consult the enclosed document you will see a list of simple conformance statements and schema changes that will get us from where we started to precisely where we ended up at the end of our meeting, which is obviously where we want to get to. In short with a few very simple schema changes and a handful of simply stated conformance statements I think we can get precisely where we need to be.  These are my recommendations for how we achieve our objectives.

 

 

Thanks,

 

-ed Koch

 

 

 

From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
Sent: Tuesday, June 28, 2011 1:35 PM
To: energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Squeezing the Message

 

Some of you contacted me off line about the Conformance statement that I sent out yesterday, and what its purpose was. Let me re-cap my understanding

 

1)      Last week, several of met at a working meeting at which a too-large Event Artifact was shared. On the call, we discussed some WS-Calendar elements that did not appear useful (for Event Signaling), some verbosity, and some repetition in the expression of Signal Information. Numerous times as we cut, the answer was I think I can justify that in conformance statements…

2)      As we worked *on the artifacts* we created a new artifact (by hand editing) that appeared to better meet the requirements as seen by that group

3)      Following that meeting Ed Koch shared  this hand-made artifact, validated by no schema, but looking more like we wanted it to.

4)      As a first step, I tried to see how close we could get to that w/o changing any of the schemas. My thought was the fewer changes from the normative reference, the better. Also, any conformance statements create a roadmap for transforming these artifacts back into the full ws-calendar. Is may also become desirable sometime in the future to communicate using more of the full flexibility of the WS-Calendar model. The close we remain, the easier *that* will be then.

5)      The Language I sent out (beginning of the thread with this message header) was a first pass at the conformance only. My work process is to start there, see how close I get when I run it through a code generator to an artifact generator and see what was left.

6)      The note stated “comments welcome” and “rough draft”. That is because I truly would welcome suggestions as to how to get further down that road, as well as any errors and omissions.

 

7)      Part of that work suggested that some improved schema definition in the area of event signal definition would help reduce payload size as well. A first draft of *those* changes is posted in the Schema work recently arrived on the OASIS site (WIP3). I welcome changes or suggestions there, as well.

 

8)      I am now turning to some time with the code, to see what I generate and ponder the next steps. The goal remains: artifacts similar in size and complexity to the ones Ed K posted last Thursday.

 

 

Tc

 


"He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche


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]