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 see my comments in your change log.