RE: proposal for faults

> Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] writes:
> "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com> writes:
> >
> > For the SOAP binding, it would be great to define the value of
> > Fault/Code/Value, Fault/Code/Subcode/Value, Fault/Reason/Text as
well as
> > Fault/Detail. I can see a point of view that suggests we don't need
to
> > describe the human-readable Fault/Reason/Text, but the others are
key to
> > machine recognition of the specific fault. (Fault/Node and
Fault/Role
> > would be generated at runtime.)
> 
> Good point. It seems that the value of Fault/Node can be computed
> based on the message reference? 

Fault/Node is an identifier for the node that faulted. This does not
seem to be a thing that would need to be described statically.

> I mean whether its client or server
> etc.. 

Generally, I don't think you can infer whether an incoming message
triggers a fault because the sender did something wrong
(Fault/Code/Value=Sender) or the receiver can't process it due to no
fault of the sender (Fault/Code/Value=Receiver).

> I don't know enough about Fault/Role to know how to compute
> that or whether it has to be a SOAP-specific binding extension.

This does not seem to be a thing that would need to be described
statically.

> Are Fault/Code/* things that needs to be specified statically or
> is it sufficient to get them off the wire dynamically? 

Fault/Code and Fault/Code/Subcode are central to the definition of a
fault -- one could argue that the Fault/Details are secondary, so if
we're going to describe faults statically, we should prioritize
Fault/Code and Fault/Code/Subcode.

How about defining an extension like wsoap:FaultCodeValue and
wsoap:FaultCodeSubcodeValue that would go in
interface/operation/{input,output}?

> Same question
> for Fault/Reason/*.

I think one could make a case that this does not need to be described
statically.

Received on Thursday, 2 October 2003 11:32:21 UTC