- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Fri, 18 Mar 2005 06:53:52 -0800
- To: "Mark Baker" <distobj@acm.org>
- Cc: <www-archive@w3.org>
> -----Original Message----- > From: Mark Baker [mailto:distobj@acm.org] > Sent: 18 March 2005 06:24 > To: Martin Gudgin > Cc: www-archive@w3.org > Subject: Re: A minor question > > (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 ." 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. > > > I don't know how to answer the question you ask about getLastFault > > because I don't know what the message look like. Perhaps > you'd like to > > provide me a schema fragment? > > 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). Gudge
Received on Friday, 18 March 2005 14:53:50 UTC