energyinterop — archive

RE: EI ResponseTypes

From: Toby Considine
To: [email protected]
Date: Tue, 13 Sep 2011 10:20:00 -0000

Response types are not codified in EMIX, so we are not restricted there… I, too, like consolidation of response. There is a natural smooth gradation from “You’re talking Gibberish” to “You talking to me?” to “What sort of Lady do you think I am” to “Not today” to “OK, but you I won’t be ready for 10 minutes” to “Yes” to “Been there, done that” I think the error type we have proposed, with the possibility of a stack, with a gradation of responses, with a gradation of severities supports this. tc "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupery Toby Considine TC9, Inc TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Email: [email protected] Phone: (919)619-2104 http://www.tcnine.com/ blog: www.NewDaedalus.com From: [email protected] [mailto:[email protected]] Sent: Monday, September 12, 2011 9:42 PM To: Edward Koch; William Cox; Girish Ghatikar Cc: [email protected] Subject: Re: EI ResponseTypes Hi Ed, it makes sense and I am usually in favor of consolidating when possible. One challenge that I see is if we try to codify the possible responsetypes for energy-interop in emix (I believe responsetype is defined in emix). Gerald R. Gray, PhD. 517.455.4824 www.guiding-principle.com Sent from my Sprint® BlackBerry® From: "Koch, Edward" <[email protected]> Date: Mon, 12 Sep 2011 19:55:23 -0400 To: <[email protected]>; William Cox<[email protected]>; Girish Ghatikar<[email protected]> Cc: <[email protected]> Subject: RE: EI ResponseTypes Jerry, You are correct that business processes and error handling are separate. One of the reasons I’m looking into this now is because in the OADR Alliance they want to collapse both the error response and the responseTypes into a single transaction, e.g. into the EICreatedEvent payload. I was thinking that the easiest way to do this was to add an optional element to the responseTYpes that references the new ErrorObject, but in fact it would might be more proper to put an optional reference to it in the EICreatedEvent payload as well as any of the other payloads where we might want to combine things into a single transaction. That just means that instead of being able to make one edit I have to go edit all the payloads, although I will point out that the current repsonseType definition has error stuff in it so it seems to fit. Maybe you should go take a look at it. Is what I’m suggesting making sense? Thanks, -ed Koch From: [email protected] [mailto:[email protected]] Sent: Monday, September 12, 2011 3:59 PM To: Koch, Edward; William Cox; Girish Ghatikar Cc: [email protected] Subject: Re: EI ResponseTypes Hi Ed, my "rememberer" remembered something after I sent that email (this update was made a few weeks ago so it took me a minute to reoriented my brain). The EiErrorObject should be added to the EiClasses however it should not be associated with responsetype. If I remember responsetype was associated with the business processes (and the original error construct was tied to emix which unnecessarily complicated the issue). Error handling is different than responsetypes associated with business processes. Gerald R. Gray, PhD. 517.455.4824 www.guiding-principle.com Sent from my Sprint® BlackBerry® From: "Koch, Edward" <[email protected]> Date: Mon, 12 Sep 2011 18:42:33 -0400 To: Gerald Gray<[email protected]>; <[email protected]>; Girish Ghatikar<[email protected]> Cc: <[email protected]> Subject: RE: EI ResponseTypes Jerry, Thanks for the response. That all sound great, but let me ask a more specific question. Should this be in the EIClasses.xsd file? From what I can tell it is not there now. If we are going to add this to the EIClasses.xsd file then I assume that we should create an EIErrorObject or EIErrorType or some sort of ComplexType resembling your intentions and attach it to the existing EIResponseType. I’m actually not voicing and opinion about what we do with it, I’m just pointing out that it does not appear to be in the schema now and if we want to get it into the schema then someone needs to turn the crank and add it. Bill - I recommend that we add this to the agenda for Wednesdays meeting and have a hopefully quick conversation followed by someone (i.e. Jerry) generating the necessary XSD snippets that Toby can add to the next release of the schema files. I’m pushing on this cause it is something the OpenADR Alliance test jig folks want an answer on. From: Gerald Gray [mailto:[email protected]] Sent: Monday, September 12, 2011 2:48 PM To: Koch, Edward; [email protected]; 'Girish Ghatikar' Subject: RE: EI ResponseTypes I had created EiErrorObject in response to the responsetypes discussion and provided a sample schema for the object to Toby for inclusion in an upcoming working draft. The EiErrorObject that I created was based on a synthesis of CIM and MultiSpeak error returns, but also based on prior conversations where it appeared that we wanted something less complicated rather than more. CIM for example, has a very robust return structure that captures error levels, e.g. information, warning, severe, in addition to being able to capture information about the application that generated the error, etc., in addition to supporting the concept of, if we sent 10 objects, we should expect 10 returns. MultiSpeak had a much simpler construct but it also had an attribute that was a holdover from its client-server roots. The errorobject that I created reflects the stated desire of simplicity, but also supporting the 1-many structure that would allow us to return an error for every object that might be sent in a payload. Of course the sample I submitted was only a sample and the TC may fold, spindle, or mutilate as needed. From: Koch, Edward [mailto:[email protected]] Sent: Monday, September 12, 2011 4:26 PM To: [email protected]; Gerald Gray; Girish Ghatikar Subject: EI ResponseTypes Gentlemen, I’m in the process of making some minor mods to the payloads and one of the things I’m doing is checking for consistency between the specification and the schemas. I noticed that on line 895 of version wd27 of the spec there is extensive discussion of Response Types. See the text below that I cut and pasted form the doc. My question is that there is a discussion in the spec of something called the EIErrorObject but I don’t see that anywhere in the schema. Assuming it was defined would it not be part of the EIResponseType? The current definition of EIRepsonseType does not have error codes or anything like that. Was the intention to leave it up to a party such as the Alliance to define these? If that is the case then can someone give me some guidance as to how what is in the spec would be mapped to the currently defined EIResponseType? The Alliance is asking about this and I’m not sure what to tell them. Thanks, -ed Koch 5.7 Response Types 895 In a service interaction responses may need to be track to determine if the transaction is successful or 896 not. This may be complicated by the fact that any given transaction may involve the transmission of one 897 or more information objects. 898 The class diagram below reflects the generic error response. The errorID will reflect the identifier of the 899 object that caused the error, for example, this would correspond to the EventID if this was EiCreateEvent 900 service operation. The errorNumber for a successful operation is 0. A non-zero number indicates that 901 some sort of error has occurred. errorDescription allows the returning system to provide some additional 902 energyinterop-v1-0-wd27 Working Draft August 21, 2011 Copyright © OASIS® 2011. All Rights Reserved. Standards Track Work Product Page 35 of 95 text that can be used to reveal the nature of the error, and optionally, a timestamp of when the error 903 occurred may be provided to further aid troubleshooting. 904 905 Figure 5-1: Example of generic error response for a service operation 906 An exhaustive list of possible errors would not be practical to enumerate, however Table 5-1 provides 907 some informative examples of the types of errors that may result from an EiCreateEvent service 908 operation. 909 Table 5-1: Example response values for EiEvent Errors 910 Service Operation Response Error Specifics Response Description Response Term Errors Notes EiCreateEvent Success Failure createdTime Event past current time createdTime Invalid time indication EiEventType Event already exists Event malformation not addressed here All Failure Any ID type No Such ID All Failure Any MRID No such MRID All Failure ServiceArea Not in geographic area