[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: State of the schemas - EiClasses
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. 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 <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? 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. TransactionName – no definition. Timestamp eliminated Now includes a datasource (perhaps a meter) and a datasetId (sub meter Identifier, e.g.) 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. 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? Enumerated strings: I *think* our standard is lowerCamel TOKEN for these. Some are UpperCamel. PartyIdType hints that it has some rules and restrictions, but as of yet does not. PartyIdType is referenced in multiple elements eventModificationNumber – what type is it eventStateId – any rules? An enumeration? marketName is a string. How is this different frm emox:marketCOntext? Any ID rules or typing?? Uid constraintId eventId offerID optID quoteID resourceID programCallID registrationID responseSchedID tenderID transactionID venID vtnID partyId 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]