W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

Re: When is a Fault a Fault?

From: Jacek Kopecky <jacek@systinet.com>
Date: Mon, 4 Mar 2002 18:05:42 +0100 (CET)
To: Christopher Ferris <chris.ferris@sun.com>
cc: Mark Baker <distobj@acm.org>, "Williams, Stuart" <skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0203041750140.24385-100000@mail.idoox.com>
 +1 here. 8-)
 The longer version:
 I don't think that an intra-node infoset to infoset transport 
binding (just passing the infoset as a parameter of a procedure 
acting as the receiver, for example) should need to pass anything 
more than the infoset.
 This discussion may soon turn to the REST unrest discussion. I'd
rather not go there, but I feel the need to say that if we make
SOAP very HTTP-centric (by following too closely the semantics of
HTTP's mechanisms) we will then try to push some of the semantics
into other protocols, in effect making them HTTP with different
syntax. Some protocols don't have native notions of, for example,
result codes, they may not even have proper notion of a result. 
So if we're not sure something will map nicely to most protocols, 
we should not mandate it as an extra-envelopial information.
 What Mark Baker is suggesting is IMHO unnecessary complexity
added for a very special kind of application. It feels like if we 
wanted to get the protocol binding to tell us whether 
mustUnderstand is really mustUnderstand.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Mon, 4 Mar 2002, Christopher Ferris wrote:

 > I don't buy this at all. Any "hint" in the underlying protocol
 > is just that, a "hint". Some protocols may not have an available
 > "hint" that can be reused (such as HTTP status response codes)
 > which suggests to me that the proper way to address this is
 > within the envelope itself. Any "hint" provided by the underlying
 > protocol is merely an optimization.
 > 
 > I would suggest that we say that a SOAP Fault is a SOAP
 > envelope containing a SOAP:Fault element as the first child
 > element information item of the SOAP:Body element information
 > item, period. That makes it abundantly clear and unambiguous
 > to a SOAP processor that this is indeed a SOAP Fault message.
 > 
 > If you wanted to support an edge case such as you describe
 > whereby a Fault element is carried in the Body of a SOAP
 > envelope (e.g. the gimme the last Fault you issued request)
 > but is not considered as a SOAP Fault message then
 > the appropriate means for doing so would be to either a)
 > wrapper the Fault element in another element that conveys some
 > harmless intent (like a SOAP RPC req/resp) or b) add a SOAP
 > extension header with mU="1" that says in effect "IGNORE the
 > Fault element in the Body of this message, it is informational
 > and NOT operational".
 > 
 > I would strongly object to requiring that a binding specification
 > be responsible for providing a mechanism for communicating what
 > amounts to little more than a "hint" to the SOAP processor. If they
 > want to go there, they are free to do so, but we shouldn't be
 > imposing any requirement that clearly cannot be readily fulfilled
 > by many communication protocols, email being but one of these.
 > 
 > Cheers,
 > 
 > Chris
Received on Monday, 4 March 2002 12:05:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT