Re: Updated proposal for issue 192

Henrik Frystyk Nielsen wrote:

 >
 > 1) The SOAP processing model which as you point out says that it does 
not know what is going on within the body. The Body EII is in other
 > words the delimiter of where the SOAP processing stops and some other
 > processing begins.
 >
Yes, my point exactly.

 > 2) The semantics of a fault is *defined* by the fault EII and
 > not by the envelope. It is within the scope of the fault EII's
 > control to indicate *when* and under what conditions it has what
 > semantics.
 >
I think we need to be careful here. The fault EII says "I am a SOAP
fault", it doesn't say "I am a SOAP fault only when I am the sole child
of a SOAP body", that is an external semantic we choose to apply (or 
not) when defining the envelope construct.

 > The latter seems to be a general question which anything that
 > potentially can be placed within a SOAP Body will have to deal
 > with: is a purchase order still a purchase order if it is not
 > within a SOAP body or packed with other stuff?
 >
My answer would be: yes it probably it is. The SOAP envelope and body
are just the packaging used to move the payload around. We explicitly
state that the spec "mandates no particular structure or interpretation
of these elements (direct children of the body), and provides no
standard means for specifying the processing to be done". By my reading
that means it is left to the application to decide whether a purchase
order accompanied by something else is still a purchase order or not.

 > The proposal that I sent defines the
 > boundaries of when a fault is a fault and when it is not. The way it
 > does that is by describing it in relationship to the context in which
 > it is used.
 >
It does, but the boundaries are a little too strict IMO, particularly in 
view of our otherwise lax rules on body contents and processing.

If we are going to keep the fault inside the body then I wonder if a 
liberal application of the robustness principle is in order instead ? 
Something along the lines of "receivers MAY/SHOULD treat a message as a 
SOAP fault if the SOAP body has a direct child of soap-env:Fault. 
Senders SHOULD generate SOAP faults such that the fault is the sole 
child of the body" ?

We might want to tighten the rules when the SOAP RPC convention is in 
use such that "senders MUST generate SOAP faults...".

 > I think it is extremely important that we indicate to SOAP users
 > that it is possible to define rules for the content of the SOAP
 > Body and that such rules are enforceable - otherwise SOAP users
 > can effectively not use the Body in any reliable manner.
 >
I agree.

Marc.

-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.

Received on Tuesday, 16 April 2002 14:26:22 UTC