RE: Issue 192 & R803

>I don't understand why making the fault a child of the 
>envelope instead 
>of the body breaks orthogonality with the envelope or changes the 
>processing model - could you elucidate further ?

Currently the processing rules are identical for a SOAP message
independent of the contents of the Body, be it a fault, a purchase
order, an event notification or something else. If we make the fault
special then we need a special processing model for that as compared to
all other possible message types.

If you on the other hand argued that we should get rid of body entirely
then I think that would be a consistent model as well. However, that
would lead us with the exact same problem of describing when a fault is
a fault as compared to merely "data". This of course is the case for all
possible message types - is a purchase order a purchase order if it is
wrapped within something else, or is encrypted?

>In the spec we don't say anything about the fault having to be 
>the first 
>child EII of the body, only that it must be a direct child and that 
>there should only be one fault EII.
>We don't disallow other EIIs within the body along with a fault and we 
>don't say anything about processing the fault or any EIIs that may 
>accompany it.

The April 11 snapshot has as part of the definition of a SOAP fault text
that limits when a SOAP fault is truly a fault [1] and when it is merely
"data" (I referred to this in my proposal):

"To be recognized as carrying SOAP error information, a SOAP message
MUST contain exactly one SOAP Fault as the only child element of the
SOAP body. A SOAP fault element information item MAY appear within a
SOAP header block, or as a descendant of a child element information
item of the SOAP body; but, in such cases, the element has no
SOAP-defined semantics."

This of course is similar to what we say about "role" and "mU"
attributes - they are only "active" when used in specific places.

Henrik

[1]
http://www.w3.org/2000/xp/Group/2/04/11/soap12-part1-1.86.html#soapfault

Received on Sunday, 14 April 2002 20:49:50 UTC