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>

> 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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:19 UTC