- From: Mark Baker <distobj@acm.org>
- Date: Fri, 18 Mar 2005 10:15:52 -0500
- To: Martin Gudgin <mgudgin@microsoft.com>
- Cc: www-archive@w3.org
On Fri, Mar 18, 2005 at 06:53:52AM -0800, Martin Gudgin wrote: > > (to www-archive) > > > > On Thu, Mar 17, 2005 at 10:27:38PM -0800, Martin Gudgin wrote: > > > All messages for which the XPath I gave below evaluates to > > true are SOAP > > > faults. > > > All messages for which the XPath evaluates to false are not > > SOAP faults. > > > > I understand that position. It's self-consistent, and also consistent > > with many toolkit implementations. But it's also not in the spec, > > The following language is in the spec > > "To be recognized as carrying SOAP error information, a SOAP message > MUST contain a single SOAP Fault element information item as the only > child element information item of the SOAP Body ." Yes, you pointed this out before. But as I pointed out, it doesn't say what you think it says. > which is what I drew my (sloppy) XPath from. > > > and > > more importantly, inconsistent with the HTTP binding. > > I don't know what the HTTP binding has to do with this discussion. As part of the SOAP 1.2 specification, it prescribes behaviour which is inconsistent with your position. > > Let's keep it simple and say that the last fault message is > > bit-for-bit > > identical with the fault that would be returned from > > getLastFault if it > > succeeded. In other words, the last fault was a fault with > > getLastFault. > > I don't believe that's allowed per SOAP 1.2 Part 1. If you really want a > getLastFault then the returned fault information must be wrapped in some > other element (either in the body or a header). Right, it isn't permitted by your interpretation of the spec, which is rather odd, no? That there's no standard way of doing something as simple as that? Seems like a clear layering/separation-of-concerns problem to me. But when using the HTTP binding, I need only return the fault via an HTTP 2xx response to distinguish it from a fault returned via a HTTP 4xx or 5xx response, to accomplish that task. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Received on Friday, 18 March 2005 15:16:11 UTC