RE: [energyinterop] Spec state

["Considine, Toby (Campus Services IT)" <Toby.Considine@unc.edu>]

I believe we have something stable in all big picture ways.

Today, I have spent generating artifacts with code, i.e., working the parts. 

The Actor/Party discussion came out of that. It breaks some tooling some of the time now, but it is not because the model is conceptually wrong, but because a detail is not right. BTW, this issue can cause problems inside the target as well.
http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-592

Small differences in naming conventions are also not model breakers, but do detract from the polish on the work.
http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-591

I suspect we will continue to have changes in cardinality in the payloads through tomorrow, as folks see them at last in mostly stable form. Please, folks, put them in Jira, not in notes to me. We are too close for me to miss one.

The Reading Type enumerations do not change the model, they should not interfere with your analysis. I think they can be clearer, If that was the only concern I had, I would say vote it out.

This comes to two large issues: Reports and Edkea.

Edkea is having the right conversations in http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-585

Reports have, to my mind, sufficiently flexibility to request, to track, and to report nearly anything. The service payloads that arrived yesterday support a wide range of common scenarios:

- report during event
- report an hour before through an hour after  an event
- report all of the VEN's customers/resources of a certain kind
- report on a list of the VENs customers
- deliver a report right now on anything at all.
- if needed (MISO) deliver a report with 6 payloads instead of 1, and let that be configured / requested on the fly

- request a report at some interval, and keep two weeks on hand of it at all times, and I will ask for it, or part of it  when I want it.

- Reports and snaps are now requested identically, and return the same Type

- do any of the reports above for the future (projections)

-support any of the above interactions outside of events, and outside of VTN-VEN requests.

The information exchanges are extensively described (and illustrated) in sections 5.4, 5.5, and 5.6

The Payloads are not yet adequately described in the Operations of Reports, to my mind.



So I would say it is stable, it is ready for requests, and it is worth examining/comparing spec and schemas in detail. As the report area comes, I see it as a separate contribution so that it can be isolated until commented on.

tc










"It is the theory that decides what can be observed."   - Albert Einstein

Toby Considine
Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
  
Email: Toby.Considine@ unc.edu
Phone: (919)962-9073 
http://www.oasis-open.org 
blog: www.NewDaedalus.com


-----Original Message-----
From: energyinterop@lists.oasis-open.org [mailto:energyinterop@lists.oasis-open.org] On Behalf Of Ed Koch
Sent: Sunday, October 23, 2011 2:19 PM
To: energyinterop@lists.oasis-open.org
Subject: [energyinterop] Spec state

Toby, Bill,

I’m going to be at the DOE most of this week and will almost certainly miss our TC meeting on Wednesday. I will of course review things as I get a chance, but the changes of late of been extensive and before I start digging into things too deeply I want to make sure the spec and schemas are in a stable state. There are a number of things I want to review/confirm, but  before I start digging into things I want to know the spec and schema is in a stable state. Does the email below imply that all the changes that Toby is aware of is in the schemas?  What about the spec?  How closely does it match the schemas? I’m probably less concerned about the UML data diagrams than I am the operations themselves. Is the report section complete?  What about the payloads?  Are the payloads now done? I’m asking about certain sections that I intend to pay special attention to.

We also need to do the validation step of mapping the OpenADR 1.0 EventState attributes to the EIEvent attributes before we vote it out for public review and I don't want to do this until I'm certain the schema's are in their near final state.


Thanks,

-ed Koch



From: energyinterop@lists.oasis-open.org [mailto:energyinterop@lists.oasis-open.org] On Behalf Of Toby Considine
Sent: Saturday, October 22, 2011 9:30 PM
To: energyinterop@lists.oasis-open.org
Subject: [energyinterop] Groups - energyinterop-1-0-schema-wd32.zip uploaded

Submitter's message
Ready for White Gloves. Review all your open issues and make comments as relates to these schemas and move to Applied if you can.


-- Toby Considine
Document Name: energyinterop-1-0-schema-wd32.zip ________________________________________
Description
Change Log for WD32
*** WD32 ***
1) Small fixes in documentation, inheritance
2) Deleted commented out items from WIPs
3) CHanges ot Paylaods, especially Report Service


*** WIP3 ***
1) EiSignal aimed at a collection of ResourceIDs, rather than a Target.
Target contains an optional collection of Resource IDs.
2) Removed Tolerance from Signal. It is normally inherited from the Active
Period, and if needed is already legal as a WS-Calendar property
3) Populated Report Type enumeration docuemntation with text from
Specification


*** WIP2 ***
1) ProgramLevel and Program Context are gone. Level and SimpleLevelContext
replace. Confusion from overloaded "Program" is gone. 

signalLevel conveys a level.
2) reports (and specifiers) now contain an option rID, used when report is
to convey or conveys multiple payloads. rID may be omited if 

report conveys a single Payload.
3) Stream is now defined as if a gluon-derivative, which MAY convey an
internal degenerate Sequence (as a colectionof intervals). THis gluon-

derivative now MAY have a duration. This is used in (4), (5).
4) If the Stream has a duration, this is inherited by each Interval in the
stream (well of course, its a gluon). This supports the pattern wherein 

every interval in the Signal/Baseline/Report/Delivery has the same
duration.
5) Snaps are gone, subsumed into reports. Reports convey the now optional
intervals (3) or a snap. The snap is a container for a payload, the 

analogue of the currentValue in a signal.
6) Report and snap requests are now identical at the top level. DIfference
is contained enitrely in the reportScheduler. In other words, Snap is 

now a particular type of report schedule.
7) PartyID added to list of things that MAY be in a Target.
8) ReportSubject and ReportDataSource are now Targets.
9) EIDelivery is a minimal stream, a simplified Report, that can be
transformed into the information model of EMIX:Delivery.
10) Extraneous IDs (remember ID conversation last week) removed
11) Changes to Enrollment, mostly to reflect new names for enrollees
12) Eliminated EiRejectEnrollType, EiRejectEnrollQualifyType,
EiAcceptEnrollType


*** WIP1 ***
1) Changes to Reports to create reportDescription, remove Report Metabase,
change dataSSource, dataSet to be derived from TargetType
2) Created types for reportSpecifiers, reports to support multiple
payloads
3) Changes to EiAvail, EiOpt types
4) Changes to Avail, Opt payloads



tc 
Download Latest Revision
Public Download Link
________________________________________
Submitter: Toby Considine
Group: OASIS Energy Interoperation TC
Folder: Standards
Date submitted: 2011-10-22 21:29:52