Major Beginning at line 1081 the description of ResponseType is described. There are a couple of challeges here. First it is probably inappropriate to define the unqiue EI response types in EMIX. Second, the enumerations are not needed. The "Yes", "No", and "Maybe" is self-defining. If a single response is sent and the error number is 0 then it is successful. If a single response is sent and the error number is anything other than 0 it is not successful.
"Maybe" comes into play when > 1 response type is returned. For example, if two response types are returned one with a 0 and one with some other number, this represents a "Maybe", but the "Maybe" does not need to be literally returned as an enumeration, the package itself, with its mixed results defines "Maybe". The system that receives these returns will still need to determine from the interaction identifiers, which return failed.
Regarding EMIX reference question: In WD26 figure 8-6 the XSDComplexType ResponseTermType has an element ext_ref_73: emixBaseTerm.
| Field | Original Value | New Value |
|---|---|---|
| Resolution | Corrected in WD27 Section 5 update use of EiErrorObject | |
| Status | New [ 10000 ] | Closed [ 6 ] |
| Status | Closed [ 6 ] | Open [ 1 ] |
The emix Base Term Type is used for market terms; I think that's been cleaned up in wd29-wip1 or so. The intent there was to say "you asked with one hour notice and the program requires 3 hours, AND you asked for 30 minutes of energy and I won't provide it for less than an hour AND...
The overall issues on responsees need to be addressed under this issue and made uniform across EI for wd29.
send 20 events, get 20 responses...looks at the responses and ORs them itself...The semantics are complex because of the complexity of what's sent. This applies to CreateEvent, ChangeEvent, response Payloads.
Other changes in Resolution
| Resolution | Corrected in WD27 Section 5 update use of EiErrorObject |
See WD27 Section 5 update use of EiErrorObject - move text earlier into patterns. wd29: Make the following changes. Delete the present EiResponseType, ResponseTermType, ResponseDescriptionType, and ResponseType. Change name of EiErrorObjectType to EiResponseType Change all payload elements to "eiResponse" and make it mandatory if there is a response. EiResponse will now have the following elements: errorNumber [1] errorID [1] - the ID (from UidType) of the thing that the error is related to - an EiEvent, a Tender, ... errorDescription [0..1] - the string, needs to be internationalizable but this is now server/client side errorTime [0..1] timestamp, optional delete "response" Describe errorNumber format following (Toby) HTTP style, where leading digit is the major code. For example, 2.. is success. 1... info 2... success 3... 4.. 5.. server error Note that a numeric string starting with '2' indicates success. |
Payload updates in pending file 20111003
| Fix Version/s | wd29 [ 10192 ] | |
| Assignee | William Cox [ william.cox ] | Toby Considine [ toby.considine ] |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Status | Resolved [ 5 ] | Applied [ 10002 ] |
Moved to closed per unanimous vote (Aaron no longer present) in TC Meeting 2011-11-09
| Status | Applied [ 10002 ] | Closed [ 6 ] |
ResponseType needs to be earlier, rather than inserted just before EiEvent responses are defined. Figure 8-6 is mis-titled as well.
I suggest moving the ResponseType description and figures to Section 5, Introduction to Services and Operations, in section 5.6, Description of the Services and Operations.
I don't understand the reference to EMIX in the description.