W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

RE: Issue 192 & R803

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Sun, 14 Apr 2002 17:49:27 -0700
Message-ID: <79107D208BA38C45A4E45F62673A434D07160EDB@red-msg-07.redmond.corp.microsoft.com>
To: "Marc Hadley" <marc.hadley@sun.com>
Cc: "Martin Gudgin" <marting@develop.com>, "Christopher Ferris" <chris.ferris@sun.com>, <xml-dist-app@w3.org>

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


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:19 UTC