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

Re: Summarizing the last 192 discussion

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
Message-ID: <20020402224638.B20848@www.markbaker.ca>
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 GMT

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