[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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. 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. 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
From: energyinterop@lists.oasis-open.org [mailto:energyinterop@lists.oasis-open.org] On Behalf Of Edward Koch Toby see my comments in your change log. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]