RE: Updated proposal for issue 192

>> My personal feeling is that it should *not* be allowed to have
>> "MyExtraStuff" as we already have a "detail" EII which can
>> contain such information as well as header blocks that can
>> contain other end-to-end information if need be.
>>
>In principle I agree, but it seems rather fragile to me to say 
>the above 
>doesn't contain a fault just because there is an additional element in 
>the body - particularly as we say elsewhere in the spec that:
>
>"Part 1 of this specification (this document) mandates no particular 
>structure or interpretation of these elements (immediate 
>children of the 
>SOAP body), and provides no standard means for specifying the 
>processing 
>to be done."

The way I tend to think of this is that we are specifying two different
parts that are fairly orthogonal:

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.

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.

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? 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.

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.

Henrik

Received on Tuesday, 16 April 2002 13:08:43 UTC