[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] State of the schemas - EiClasses
|
Comment with respect to the following: 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. Ø We should not tightly couple the reporting interval with how many data points are packaged with each message. It may be that we measure at 5 minute intervals, report at 15 minute intervals and “package” data for each report that covers the last 2 hours. That means that for each message at the 15 minute reporting interval there may be data that is redundant with the previous message, but this is a common method of dealing with “missed” reports and insures higher reliability of the data stream. Thanks, -ed Koch From: William Cox [mailto:wtcox@CoxSoftwareArchitects.com] Notes interleaved. Good overview of issues. William Cox
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) <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. 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 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.”
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]