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] RE: wd29 wip2 changes


Ed and all --

In our task list (http://www.oasis-open.org/committees/download.php/43691/EI%20PR03%20work%20items%20D11%2020110927.xls ) there's one outstanding item directly related to some of these discussion points.

Task 1:
Factoring, normalization, interval squeezing, and conformance (472, 402, etc.); architectural consistence and interval issues
In earlier working drafts we'd created several parallel things inheriting respectively from VcalendarType and ArtifactBaseType to create intervals with  information attached to them; these structures led to streams as a single, consistent approach, built on what we've learned about factoring in the EITC.

BUT there are a number of specific issues and redundancies. One that jumped out at me is Ed's comment on 8 below (others I'll spell out in separate topic emails):
>> None of this new interval stuff makes any sense to me. Can you send out some sample xml for EIEvent?
I agree completely -- I was also confused here, and as I dove in I saw that part of my confusion was caused by an additional set of redundant classes/ComplexTypes in EiClasses.xsd around line 908/ documentation 9.8 that should have (IMO) gone away as the streams commonality was applied.  These include a separate kind of interval --  we need one kind of interval, not several, as we identified many weeks ago.

Those types aren't used, but confuse at least this reader.

The streams commonality is largely there, but there are issues in and around baselines (at least), as well as artifact-level parallel structure with PR02 (intervals, local IDs, only values in each).

I'll start separate email threads on additional points and some new ones - like the clear extension point for signal streams of application data (as in the SEP examples we've discussed).

Thanks!

bill
--
William Cox

Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax

On 10/2/11 11:09 AM, Edward Koch wrote:
Toby - see my comments below:
 
 

From: energyinterop@lists.oasis-open.org [energyinterop@lists.oasis-open.org] On Behalf Of Toby Considine [Toby.Considine@gmail.com]
Sent: Sunday, October 02, 2011 8:05 AM
To: Edward Koch; Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org
Subject: [energyinterop] RE: wd29 wip2 changes

Thanks Ed. Let me answer the ? which can be answered quickly in this note, to frame the long answers separately…

 

1) Added reference to EMIX Resources

Ed>> What does this mean? What is the change? Please be more specific.

 

Tc>>> A Comment submitted by the OpenADR Alliance complained that there was no reference to the EMIX Resource Schemas in the EiClasses.

http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-506 Personal belief is that EMIX and all its derivatives were already in the schemas—that is how derivation from abstract classes works.  

 

Whether there needs is a useful  in “Tooling Schema” that explicitly binds these and other schemas together is outside of scope. Such a “Tooling Schema” would  assist in auto-complete and validation during tooling or in some other means. I actually have uses such tooling schemas in validating each release of WS-Calendar, EMIX and EI. Such a Tooling Schema would presumably include out-of-scope derivative, including potential ones that the Alliance might use for SEP Derivations in the Application Specific Extension classes.

 

I guess what tipped me the other way is that Ramps are mentioned in the specification and never defined in the directly referenced schemas. The entire change is adding line 7 of EiClasses.xsd:

                <xs:import namespace="http://docs.oasis-open.org/ns/emix/2011/06/power/resource" schemaLocation="EMIX/resource.xsd"/>

 

3) Added Optional Program Context to Ei Market Context

Ed> We've discussed this many times in the past and decided to leave these sort of context attributes to version 2.0 of the spec when we might have more time to define them properly including the necessary services to query for them. I think I understand why you want this, but in my opinion this is completely the wrong way to do it. What you are trying to do is establish a context for signals "levels". The reality is that this context should be applied to a particular signal context not to EVERY signal of type level. Furthermore this is only applicable to a certain type of signal when in fact EVERY signal type AND every instantiation of a signal should have attributes that define bounds on their values.  Even furthermore there are a lot of so called context attributes beyond just min and max values that one should define. And yet even furthermore I don't believe that these type of context attributes belong in the event. I believe they belong in its own data structure that can be queried with a yet to be defined service. I recommend that you change this to a uri so that it can be a simple reference to the more robust program/signal contexts that we will develop in the future.

 

Tc>>> This must be answered in a meeting. There was strong guidance on including this at various times from both chairs, and this solution was discussed for a long time at the UCAIug meeting in Miami.  AN essential feature of PAP09 is that a device be able to do minimal discovery of the local context, i.e., that a device made by a manufacturer in state/country A be able to configure itself in State/Country/Market/Regulatory environment B without human intervention. This is needed for that, and is part of the context of this market.

 

There are three times when the device needs to be able to understand this: when signing up for a program, when responding to an event based on the program, and when re-discovering the market after swap-out/replacement/etc. This suggests that is be conveyable (not the stronger conveyed) during Enrollment (which we are not specifying), during Event, and during Status,  In all cases, it only needs to know this if it is in a market context that actually uses Programs.

 

To meet your concerns, it, and everything in the EiMarketContext conveyed during an even with the exception of the URI that identifies the Context, is optional.

 

EK>>>> I was not questioning the motivation for having this sort of attribute, I was rehasing some of our previous conversations on this topic and pointing out that what you have done in an attempt to satisfy your stated requirements is wholly inadequate and has little if any value in helping someone interpret the signals they might recieve in an event. Crafting a solution that addresses your stated requirements adequately will add significant time to the schedule and represents a huge addition to the spec.  I thought this was clear in our previous discussions which is why we decided to leave this to a future version of the spec, but if you want to spend cycles revisiting that decision then so be it.

 

6) CurrentValue is now CurrentLevel, an enumerated set of elements (choice, 1 per instance) to handle levels, prices, setponts and even application specific info

Ed> Why did you change the name??? You seem to have defined it in a way that is different than its intended semantics. Also why did you change signalLevel to programLevel?  I don't agree with this name change.

Tc>>>I am not wedded to this name, but there is something more important going on under the covers. We now have an whereas before is contained only a single number, now it contains exactly the same object/set of choices that is potentially in each signal interval. Conformance statements will state that the same choice be made in each Interval in the stream and in the Current*** if present..

 

The semantics in WD29-WIP2 (and in the proposed chapter 4, also posted yesterday) is that Each Interval, and the Current*** if present, contain a Signal Payload. The conformance in the Spec says that all Signal payloads in a given Signal be the same, i.e., every one is a Price, or every one is a program level, or every one is an EMIX, or every one is a setpoint…. This was part of creating the consistent pattern for all Streams-derived objects. My plan is that we will use the same semantics for Baselines and for Feedback, including the many Steffes feedbacks. See (7, 8)

 

7) EITC:Interval now is a container for the streamPayloadBase

 

8) SignalPayload, derived from StreamPayloadBase, is not the common elment for (6) and (7)

 

>> None of this new interval stuff makes any sense to me. Can you send out some sample xml for EIEvent?

Tc>> Will by separate cover after breakfast.

 

EK>>> Consider the following: (a) I'm pretty  good with xsd files, (b) there are very few if any people as intimate as I am with the previous versions of the schemas and how they should be used (c) I don't know how to take the wip2 schemas you have produced and do what we have been doing in the Alliance for many months now with the previous versions of the schema. Whatever your motivation may have been for making all these changes there is something fundamentally wrong with that equation, especailly at this late a date.  Given my history with this process, If I can't do it then how is anyone else expected to?  I'm still hoping and praying that we can express events and signals in the same fashion that we have been doing in the Alliance for many months now, but the magnitude of the changes that you have made to the schemas at this late date is frightening.

 

 

Thanks

 

tc


"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."

-Antoine de Saint-Exupery


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: energyinterop@lists.oasis-open.org [mailto:energyinterop@lists.oasis-open.org] On Behalf Of Edward Koch
Sent: Sunday, October 02, 2011 1:20 AM
To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org
Subject: [energyinterop] wd29 wip2 changes

 

Toby see my comments in your change log.

 



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