Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: wd26
    • Fix Version/s: wd29
    • Component/s: spec
    • Labels:
      None
    • Environment:

      Gerald Gray

    • Proposal:
      Hide

      Put the ResponseType in EI rather than EMIX
      Remove enumerations, "Yes", "No", "Maybe"

      Show
      Put the ResponseType in EI rather than EMIX Remove enumerations, "Yes", "No", "Maybe"
    • Resolution:
      Hide

      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.

      Show
      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.

      Description

      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.

        Attachments

          Activity

          Hide
          william.cox William Cox (Inactive) added a comment -

          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.

          Show
          william.cox William Cox (Inactive) added a comment - 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.
          Hide
          gerald.gray Gerald Gray (Inactive) added a comment -

          Regarding EMIX reference question: In WD26 figure 8-6 the XSDComplexType ResponseTermType has an element ext_ref_73: emixBaseTerm.

          Show
          gerald.gray Gerald Gray (Inactive) added a comment - Regarding EMIX reference question: In WD26 figure 8-6 the XSDComplexType ResponseTermType has an element ext_ref_73: emixBaseTerm.
          Hide
          william.cox William Cox (Inactive) added a comment -

          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.

          Show
          william.cox William Cox (Inactive) added a comment - 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.
          Hide
          william.cox William Cox (Inactive) added a comment -

          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

          Show
          william.cox William Cox (Inactive) added a comment - 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
          Hide
          william.cox William Cox (Inactive) added a comment -

          Payload updates in pending file 20111003

          Show
          william.cox William Cox (Inactive) added a comment - Payload updates in pending file 20111003
          Hide
          toby.considine Toby Considine (Inactive) added a comment -

          Moved to closed per unanimous vote (Aaron no longer present) in TC Meeting 2011-11-09

          Show
          toby.considine Toby Considine (Inactive) added a comment - Moved to closed per unanimous vote (Aaron no longer present) in TC Meeting 2011-11-09

            People

            • Assignee:
              toby.considine Toby Considine (Inactive)
              Reporter:
              gerald.gray Gerald Gray (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: