RE: Proposal and issues surrounding MustUnderstand faults

In fact this potentially ties in nicely with the parallel work on
ordering. If we have a mechanism for expressing ordering and possible
constraints between header entries then this can be used (with the
proper marking) as metainformation about what a message should contain
in case it didn't as well as saying what is to happen within THIS
message.

In other words, one can talk about THIS message and about other messages
using the same language.

This of course also ties in with WSDL which talks about what should go
into a message. Could a fault message (in case we know where to send a
fault message) contain a piece of WSDL saying what is needed in order
for a message to succeed?

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

>-----Original Message-----
>From: Glen Daniels [mailto:gdaniels@macromedia.com] 
>Sent: Friday, May 11, 2001 16:24
>To: xml-dist-app@w3.org
>Subject: Proposal and issues surrounding MustUnderstand faults
>
>
>Hi folks!
>
>On this week's conference call, I volunteered to take a crack 
>at a proposal for dealing with the difficulty of getting back 
>useful information regarding which headers in particular were 
>the cause of a MustUnderstand fault.
>
>This message proposes two possible solutions for the problem, 
>and suggests a bit more exploration into the issue of faults 
>in general.
>
>As background/context, you can read the description of the 
>issue at [1].
>
>** PROPOSAL 1 : Use the <Fault> element
>
>This proposal involves EITHER extending the Fault element with 
>another sibling to <faultcode>,<faultactor>,etc. :
>
><faultcode>MustUnderstand</faultcode>
><faultheaders>
> <myNS:Header1 xmlns:myNS="http://some.com"/>
></faultheaders>
>
>OR changing the rules of section 4.4 to allow the <detail> 
>element to carry information relating to headers, and adding 
>the same <faultheaders> element underneath <detail>.
>
>** PROPOSAL 2 : Use the header
>
>A similar proposal involves echoing back the offending headers 
>in the <SOAP-ENV:Header> section of the fault response:
>
><Envelope>
> <Header>
>  <SOAP-EXT:MisunderstoodHeaders>
>   <myNS:Header1 xmlns:myNS="http://some.com" mustUnderstand="1">
>     Nobody understands me.
>   </myNS:Header1>
>  </SOAP-EXT:MisunderstoodHeaders>
> </Header>
> <Body>
>  <Fault>
>   <faultcode>MustUnderstand</faultcode>
>  </Fault>
> </Body>
></Envelope>
>
>The second one more cleanly fits the SOAP extensibility model, 
>I think.  This is potentially one of the "normative 
>extensions" we could add to the spec, since while not 
>absolutely essential, it would be very handy if most 
>processors out there implemented this.
>
>On a slightly broader note, I think in parallel with our 
>discussion of the potential symmetry and/or differences 
>between headers and bodies, it would be good to bring up how 
>Faults are generated, and look carefully at the current SOAP 
>assumption that there is exactly one Fault per message, with a 
>single <faultcode>.  While convenient in some ways from a 
>processing point of view, this does generate a contended 
>resource - and there may be ways in which fault information 
>can be orthogonally added to a message in the same way 
>extension data will be.  I don't want to go into this too 
>deeply in this note, but did want to sprout the seed of this 
>discussion, which came up on the call.
>
>--Glen
>
>[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/0097.html
>
>
>

Received on Wednesday, 16 May 2001 15:40:33 UTC