- From: Prasad Yendluri <pyendluri@webmethods.com>
- Date: Wed, 22 May 2002 13:44:54 -0700
- To: Jacek Kopecky <jacek@systinet.com>
- CC: fablet@crf.canon.fr, keithba@microsoft.com, prasad.yendluri@webmethods.com, Waqar.sadiq@eds.com, sanjiva@us.ibm.com, ksankar@cisco.com, Web Services Description mailing list <www-ws-desc@w3.org>
Jacek, I agree permitting multiple (alternate) response is good but, I disagree with taking away (the current) multiple alternate faults if we can not have multiple alternate responses. Consistency is not a factor here IMO. I am ok with both or current one. Regards, Prasad Jacek Kopecky wrote: > Prasad, > you made an excellent point about 1b, I agree it's not a good > approach now. > As for 1a, I think we need to be consistent - why have different > faults and not different successes? I'd be OK with either both or > none. > > Jacek Kopecky > > Senior Architect, Systinet (formerly Idoox) > http://www.systinet.com/ > > On Tue, 21 May 2002, Prasad Yendluri wrote: > > > > 1) RequestResponseOperations references a successful response > > > Message and a list of failure response Messages. I believe we > > > should change this in one of the two ways below (I really don't > > > know which one is the better one): > > > > > 1a) One success response Message and one failure response > > > Message. Rationale - we don't describe possible variations of the > > > success response, why should we describe the variations of the > > > failure response? > > > > <PY> > > I think the current way of multiple faults is desirable (though only one > > of them could be returned). This allows for capturing all error > > (fault-conditions) that an operation could result in. That is an > > operation can fail for multitude of reasons and it should be possible to > > enumerate them. It might be the case that one fault message (say at the > > binding level) might be able to capture thins but, at the abstract > > level it would be desirable to permit enumeration of > 1 fault > > conditions. > > > > If any I would call for permitting alternate +ve responses as well (we > > have an issue that captures this). > > </PY> > > > > > 1b) A set of response Messages without distinguishing between > > > failure and success responses. Rationale - the distinction > > > between a failure and a success is sometimes fuzzy and belongs to > > > the application. > > > > <PY>I have the opposite view. I think it is very useful to see the > > failure conditions as separate from positive response conditions at > > abstract level. Other wise how to you define flows that are conditional > > ?</PY>
Received on Wednesday, 22 May 2002 16:41:07 UTC