energyinterop — archive

State of the schemas - EiClasses

From: William Cox <[email protected]>
To: [email protected]
Date: Sat, 04 Jun 2011 19:26:00 -0000

Rish - comments interleaved. Thanks! bill -- William Cox Email: [email protected] Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax On 6/4/11 2:42 PM, Girish Ghatikar wrote: [email protected] type= cite >Some quick notes. - I agree with Bill that both measurement interval and reporting interval are needed by different programs and purposes (e.g., forecast may need longer reporting interval, however, A/S telemetry for load shed may require it to be all the way down to 4-second). Need to look at what program requirements we're trying to facilitate. - Not don't understand ResourceTarg et (cardinality 0..* here). I thought we determined the need to have at least one resource the information is coming from -- hence the cardinality of 1..* Yes, you're right. [email protected] type= cite > - A dataSource can extend beyond the meter (meet service provider requirements) and can be more than one (e.g., whole-building vs. lighting, HVAC, etc.) -- the datasetIDs are most likely associated with it. It's different from other requirements. I think it's an issue of what a VEN MAY convey, not must... [email protected] type= cite > Thanks, -Rish On Sat, Jun 4, 2011 at 11:20 AM, William Cox < [email protected] > wrote: Notes interleaved. Good overview of issues. Thanks! bill -- William Cox Email: [email protected] Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax On 6/2/11 9:40 AM, Toby Considine wrote: Summary of changes to EI-Classes Schema in Ed Koch’s sumission EiMarketContext now has an optional emix:MarketContext. Observation: eiMarketContext now identified with a uid. emicMarketContext is solely a uri-style uid. If eiMakretContext has both, possibility of some sort of collision/incompatibility. As EI often is a transport for “emixes”, removes the possible conformance issue of matching the EiMarketContext with that in EMIX. Also removes alternate rule that all packages inherit from the larger context. Seems right to me. eiFeedback Changed from < xs:complexType name = EiFeedback > < xs:sequence > < xs:element ref = eitc:eventID minOccurs = 0 maxOccurs = 1 /> < xs:element name = feedbackInfo type = xs:anyType minOccurs = 1 maxOccurs = 1 /> < xs:element ref = eitc:resourceID minOccurs = 0 maxOccurs = unbounded /> < xs:element ref = ts:timeStamp minOccurs = 1 maxOccurs = 1 > < xs:annotation > < xs:documentation > Feedback TimeStamp </ xs:documentation > </ xs:annotation > </ xs:element > < xs:element ref = eitc:transactionName minOccurs = 0 maxOccurs = 1 /> < xs:element ref = eitc:venID minOccurs = 0 maxOccurs = 1 /> </ xs:sequence > < xs:attribute ref = eitc:schemaVersion use = optional /> </ xs:complexType > To (Ed's EiFeedback schemas) Per our discussion on Resource IDs this should be aligned with ResourceTarget (cardinality 0..* here). Other comments from our June 1 meeting notes. Definitely the right direction. Bundling and schedule for feedback - first comment below; I'll follow up there. < xs:complexType name = EiFeedback > < xs:complexContent > < xs:extension base = eitc:EventBaseType > < xs:sequence > < xs:element ref = eitc:eventID minOccurs = 0 maxOccurs = 1 /> < xs:element ref = eitc:resourceID minOccurs = 0 maxOccurs = unbounded > < xs:annotation > < xs:documentation > ??? </ xs:documentation > </ xs:annotation > </ xs:element > < xs:element ref = eitc:transactionName minOccurs = 0 maxOccurs = 1 > < xs:annotation > < xs:documentation > ??? </ xs:documentation > </ xs:annotation > </ xs:element > < xs:element ref = eitc:venID minOccurs = 1 maxOccurs = 1 /> < xs:element name = dataSourceID type = xs:string > < xs:annotation > < xs:documentation > This is the source of the data within the VEN, i.e. meter1 . </ xs:documentation > </ xs:annotation > </ xs:element > < xs:element name = dataSetID type = xs:string > < xs:annotation > < xs:documentation > This is the identifier for the data set within the dataSource, i.e. phase1 </ xs:documentation > </ xs:annotation > </ xs:element > </ xs:sequence > < xs:attribute ref = eitc:schemaVersion use = optional /> </ xs:extension > </ xs:complexContent > </ xs:complexType > Discussion: Most significant: Now derived from EventBase, meaning it can apply to a schedule. Does this mean that we could collect feedback at 15 minute intervals (schedule) and send at the end of the day? Do we need a message for whter Feedback should be accumulated or shared live? Yes we do. The measurement interval addresses how often it should be measured; the reporting interval addresses how often or how many feedback items are packaged. Schema now calls out undefined items by giving them an annotation “???”. This makes the object appear much larger, but it is not. ResourceId. Is it the Asset sneaking back in? Is it an MRID? Is it a virtual construct for an aggregator? Lots of discussion Wednesday, few conclusions, general sense that whateveriti is, it needs to match something similar in enrollment. Noteworthy that schema as pointedly unable (“???”) to define. We identify ResourceTarget in the EiEvent; the Resource is in the context of the VEN, and the information it delivers to the VTN. See comments below on ID/mRID. An aggregator must create a resource to bid into a market; that reflects its aggregation. The VTN presentation of an aggregator will know about the resources the aggregator can call on, and the aggregator does its magic to figure out what it can safely and economically bid. TransactionName – no definition. Timestamp eliminated Which timestamp? If we deliver a Schedule then we're fine - the applicable Interval identifies what the timestamp was used for. Now includes a datasource (perhaps a meter) and a datasetId (sub meter Identifier, e.g.) I think this is an Interface from EMIX, as there are many ways of measuring, not just a meter. Not sure where the data is, though. EventDescriptor. eiMarketContext now optional (minOccurs=0). See discussion under eiMarketContext. EiEventSignalType. More precise cardinality, including emix:marketContext as above. Added “CurrentValue as a schedule free addition to be alongside schedule w/ all optionality of messages w/I each schedule. As long as it's a cached value, valid when sent, that's fine; but the value(s) in the EiEvent family control. I have no issue with caching (and using the appropriate type to identify whether it's a multiplier, adder, simple level, etc) General Issues in Schema: There are a number of elements that are defined “in-line”. We may wish to promote them and use them by ref in the types… eiBusinessSchedule can be replaced through direct reference to xcal:vavailability Intervals. The EiInterval still looks like a conforming ws-calendar interval. The reduction in optionality is useful. Open issue whther ot stick with eiIntervals or incorporate by reference. May need to produce some examples to finalize decision. Even ws-calendar may benefit from demonstration of conforming spec that has been deliberately tightened up. One issue: dtstart does not include time zone id as it is conformed away from ws-calendar. Do we go pure UTC? Inherit a single tzid context for an entire event? I think that mixing timezones in a single event is highly risky at best - I recommend putting it in the EiEvent and not putting it in the Intervals. A more general inheritance rules might be useful here, but I see only negatives to including (repeating) the timezone with each dtStart. Speaking of flabby XML... Enumerated strings: I *think* our standard is lowerCamel TOKEN for these. Some are UpperCamel. I think that's right. PartyIdType hints that it has some rules and restrictions, but as of yet does not. I'd delete the hints...part of the more general ID (see below) PartyIdType is referenced in multiple elements We need a single type to inherit from - see below eventModificationNumber – what type is it unsigned 0, 1, 2, ... - it's really a generation number sort of thing. eventStateId – any rules? An enumeration? Not sure on this one. marketName is a string. How is this different frm emox:marketCOntext? marketContext is a global element; marketName is a human-readable string that gives the name of the market, e.g. PGE_Program_32 or NYMEX Any ID rules or typing?? I think the structure should be Uid is a subclass of string All ID s are subclasses (do we need a substitution group?) of Uid (or UidType) Uid constraintId eventId offerID optID quoteID resourceID programCallID registrationID responseSchedID tenderID transactionID venID vtnID partyId All Names are human readable strings, and inherit from string (or probably better) a NameType that is a null extension of string. Generic strings? agreementName partyName partyRole signalName transactionName “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. Toby Considine TC9, Inc TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Email: [email protected] Phone: (919)619-2104 http://www.tcnine.com/ blog: www.NewDaedalus.com -- Rish Ghatikar Lawrence Berkeley National Laboratory 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720 [email protected] +1 510.486.6768 +1 510.486.4089 [fax] This email is intended for the addressee only and may contain confidential information and should not be copied without permission. If you are not the intended recipient, please contact the sender as soon as possible and delete the email from computer[s].