[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Spec state
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, Im 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? Im 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? Im 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]