[OASIS Issue Tracker] Updated: (ENERGYINTEROP-499) EI error return is unduly obfuscated

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

William Cox updated ENERGYINTEROP-499:
--------------------------------------

    Resolution: 
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.

  was:Corrected in WD27 Section 5 update use of EiErrorObject


> EI error return is unduly obfuscated
> ------------------------------------
>
>                 Key: ENERGYINTEROP-499
>                 URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-499
>             Project: OASIS Energy Interoperation TC
>          Issue Type: Improvement
>          Components: spec
>    Affects Versions: wd26
>         Environment: Gerald Gray
>            Reporter: Gerald Gray
>            Assignee: William Cox
>             Fix For: wd29
>
>
> 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. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira