wd29 wip2 changes

[Edward Koch <ed@akuacom.com>]

Toby see my comments in your change log.

 

Change Log for WD29

*** WIP2 ***
1) Added reference to EMIX Resources
> What does this mean? What is the change? Please be more specific.

2) Added ApplicationSpecificExtensions to MarketContext (static info), Signal (both in currentLevel and in each interval), and to Feedback. The intended purpose is to support Application Specific (SEP, ClimateTalk, et al.) communications that are outside the scope of Energy Interop
> OK

3) Added Optional Program Context to Ei Market Context
> 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.

4) Added Optional Standard Terms Context to Ei Market Context (Recommend that we have service interaction to request full EI Market Context as identified by the emix:MarketContext uri
> OK

5) Added optional list of Resource IDs to ResourceTarget
> OK

6) CurrentValue is now CurrentLevel, an enumerated set of elements (choice, 1 per instance) to handle levels, prices, setponts and even application specific info
> 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.

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

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

9) Active Period durations (degenerate Intervlasexpressed as Properties) are now named properly to both meet ICalendar naming conventions for legal extensions and to include "ei" as a prefix.

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

Payloads are being worked  on by Bill, so I have not touched them.
Feedback and Baselines need some further work to allign with apporaches in Streams, 

Other than that, this feels pretty coherent.

*** WIP1 ***
1) Developed Streams, and used Streams as basis for all Signals, Baselines, and Feedback
2) Abstracted all WS-Calednar derivatives so they fit in streams, renamed to meet WS-Calendar naming requirements, particularly for the Durations in the ActivePeriod
3) Defined a SignalPayload Type, that is common to all signals (also usable as CurrentLevel). THis needs to echo back into the Streams diagram in the proposed Section 4
4) Eliminated redefintions of WS-Calendar attributes, as this is now accomplished by the comformance in Streams.
5) Changed EventSchedule/EventSchedules to ActivePeriod/EventSignals (535)
6) Refactoring around streams/payloads sharply reduced the number of signals. This is consistent with the streams document, now merged  into proposed chapter 4.
7) Array of ResourceIDs in the EiEvent restored to array of ResourceTargets(532)
8) Misc Definitions/Annotations

Sorry, the DIFF just terns the entire schema colored...

I will work on coding against this to validate that it works.

tc