Notes interleaved.
Good overview of issues.
Thanks!
bill
--
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
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.