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 09:38:07 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:20 GMT