Re: Summarizing the last 192 discussion

On Wed, Mar 27, 2002 at 10:26:40PM -0500, Mark Baker wrote:
> > If the use case of asking the server to return the last fault is important, 
> > then it should be important not just for the HTTP binding but for all 
> > bindings.
> 
> For all application protocol bindings, yes, I believe so.  Transport
> protocols, when used rather than extended, expose no notion of "failure"
> or "success", so it's not a concern.
> 
> But yes, my proposed solution to this issue when I raised it[1] was this;
> 
> "1) update the binding framework to state that each binding should
> declare that the authoritative determinant of whether a message is a
> fault or not should be the underlying protocol"
> 

I suppose that is what worries me most!  I just don't understand
why the intent of the message lies someplace outside of the SOAP
Envelope.

> (though that was intended to be only for application protocols)
> 
> >  I would like to know how other transports and bindings 
> > should/would handle this use case?  It seems to me that relying on 
> > information outside of the SOAP Envelope to determine how to interpret the 
> > meaning of the Envelope or the Fault is dangerous.  Would it make sense to 
> > add an attribute flag to the fault, something like fakeFault="true"?
> 
> I suppose that's equivalent to the "wrapping" proposal that Chris and
> Stuart discussed.  For transport protocols, this may be of value.  For
> application protocols, it's redundant IMO, since the application
> protocols themselves are the wrapper.
> 
>  [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0007.html
> 

It doesn't seem to be redundant to me, but necessary for this use
case.  The full intent of the message should be in the SOAP Envelope
and if the application protocol binding needs to expose some redundant
information for its purposes then so be it.

David

Received on Wednesday, 27 March 2002 22:54:45 UTC