Fantastic. It sounds as though there may be a base from which to
start. I assume you're volunteering to be one of that team, then?
;) Any other volunteers?
This needs to go to the EI list as well but I don't want to cross
post. Do you want to send a separate email since you know about the
previous work from the EI perspective?
-A
Girish Ghatikar wrote, On 4/4/2011 11:51 AM:
BANLkTikQH8YXnB4ve59HmrH3igZx-U4f-w@mail.gmail.com"
type="cite">Ann,
I like your suggestion. In fact, this was the exercise we'd done
some time back and has to be revisited.
Thanks,
-Rish
On Mon, Apr 4, 2011 at 11:21 AM, Anne Hendry
<ahendry@pacbell.net>
wrote:
Yes, I've seen quite a few similar questions go by on both lists (EI
and EMIX). Perhaps there should be a small cross-TC team (maybe a
couple of people from each) to hammer this out.
We could really use an architecture diagram.
Perhaps such a team could create one in such a way that either it was
two parts, one representing each TC domain and the boundary interfaces
showing where/how the two fit together, then we could incorporate each
into the respective specs, or one single diagram (similarly clarifying
the interfaces) and both TCs could use the same diagram.
Either way, it's something we could use sooner than later.
-A
Ed Cazalet wrote, On 4/3/2011 5:48 AM:
Excellent
Point Ann. We need to use the terminology of
messages for EI and EMIX carefully, if at.
On
a related point will EI provide messages? EI
has something to do with interactions to convey EMIX Products (incl
price).
But
what is normative in EI? If I use getTransaction instead of
requestTransaction with the same EMIX Payload am I violating the EI
spec?
In
the Introduction sections, both the EI and EMIX specs say they each
provide
"... a set of messages to communicate price ... ". 1
To have them both say they provide the same thing blurs the line of
where EI stops and EMIX starts.
The terminology could use some clarification/definition. I'd propose
something more along the lines of EMIX providing "an XML vocabulary for
communication of Price and Product information", or something similar,
to distinguish it from getting into the messaging / communication
services context of EI.
Does anyone else have suggestions/opinions on this? I think we have
several issues around clarification of EI/EMIX boundaries so if that is
in process perhaps this can be added to the list. I don't know how
those are being tracked since they're between TCs.
-A
1 EMIX wd22 .doc lines 176-177:
"This document defines a set of messages to communicate Price and
Product definition for power and energy markets ..."
1 EI wd22 .pdf line 10:
"Energy Interoperation defines a set of messages to communicate price,
reliability, and emergency conditions ..."
--
Rish Ghatikar
Lawrence Berkeley National Laboratory
1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
GGhatikar@lbl.gov
| +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].
|