Re: Proposed resolution of issue 37

+1

I'd add the faultcode extensibility (one can create their own
namespaced faultcodes) to the list. 8-)

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/



On Wed, 24 Oct 2001, Henrik Frystyk Nielsen wrote:

 >
 > I took an action item to write up what SOAP 1.2 provides in the way of
 > extensibility relating to issue [1] which refers to requirement R302 [2]
 > from the XML Protocol Requirements document. The description of the
 > issue is as follows:
 >
 > "SOAP1.1 defines a vocabulary with certain types of extensibility. XML
 > Protocol requirements declare a need for extensibility which supports
 > "decentralized extensibility without prior agreement". It's not clear
 > whether the types of extensibility in SOAP are adequate for this
 > requirement."
 >
 > SOAP provides an extensibility mechanism that allows for addition of an
 > open-ended set of header blocks to any SOAP message. The default SOAP
 > processing model for such blocks is that they are optional and intended
 > for the ultimate recipient. This behavior can be overridden by using the
 > "mustUnderstand" and "actor" SOAP attributes.
 >
 > Header blocks are identified by the fully qualified element name of the
 > outermost element of the block allowing for deployment of both publicly
 > defined header blocks as well as privately defined header blocks defined
 > in a decentralized manner.
 >
 > A SOAP sender can in principle add any header block to any SOAP message
 > independently of any other block and without prior agreement with the
 > recipient of the message. It is not within the scope of SOAP 1.2 to
 > describe whether or how header block interactions are defined or
 > enforced.
 >
 > A SOAP receiver can generate a SOAP fault while processing a message if
 > required header blocks are not present. SOAP 1.2 defines a
 > "mustUnderstand" fault code along with a mechanism for indicating which
 > blocks were not understood without prior agreement with the sender.
 > While the SOAP 1.2 envelope itself does not define a mechanism for
 > routing or otherwise returning SOAP fault messages, such mechanisms may
 > be provided by the underlying protocol or by additional SOAP modules.
 >
 > Given this, I would claim that SOAP 1.2 fulfills both the
 > "decentralized" and the "without prior agreement" part of this
 > requirement and will propose that we close issue 37.
 >
 > Henrik Frystyk Nielsen
 > mailto:henrikn@microsoft.com
 >
 > [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x37
 > [2] http://www.w3.org/TR/xmlp-reqs/#z302
 > [3] http://www.w3.org/TR/soap12-part1/#mufault
 >

Received on Thursday, 25 October 2001 05:00:38 UTC