- From: Mark Baker <distobj@acm.org>
- Date: Tue, 2 Apr 2002 22:46:38 -0500
- To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Cc: Mark Baker <distobj@acm.org>, noah_mendelsohn@us.ibm.com, "Williams, Stuart" <skw@hplb.hpl.hp.com>, xml-dist-app@w3.org
Henrik, > Sorry for jumping in here and maybe I am missing something but I think > we may be able to define when a fault is a fault without compromising > the integrity of our spec (maybe this according to Noah [1] is having > our cake and eating it too). Would it not work to say the following: > > A) A SOAP processing failure results in the generation of a SOAP fault > [2] > > B) An HTTP processing failure results in the generation of an HTTP > status code describing the failure [3] > > C) The SOAP binding to HTTP defines the mapping between SOAP faults and > HTTP status codes (the TBTF is currently discussing issue 196 [4] > which is related) > > If any of these statements are not true then we have a broken > implementation. This appears to be the status quo, right? Given the obvious split in opinions here, and that the default HTTP binding doesn't say what to do with a fault on a 200 response, I'm confident that there will be interoperability problems. At this point, I'd actually be happy for us to say that the default binding does *not* support the chameleon use, and that a fault over 200 is a fault. At least interoperability wouldn't suffer, even if that interoperability wasn't between parties using the chameleon view (which is barely used anyway, except perhaps for some EDI style solutions). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Tuesday, 2 April 2002 22:54:15 UTC