W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2002

[amtf] Multiple responses? (was: Re: First shot at Abstract Model)

From: Jacek Kopecky <jacek@systinet.com>
Date: Wed, 22 May 2002 15:38:00 +0200 (CEST)
To: Prasad Yendluri <pyendluri@webMethods.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>
Message-ID: <Pine.LNX.4.44.0205221438550.31247-100000@mail.idoox.com>
 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