Re: Proposal for hierarchical fault codes

 Gudge,
 Is there a possibility to make it the following way?

<soap:Fault xmlns:soap='http://www.w3.org/2001/09/soap-envelope' >
  <faultcode>
    soap:Receiver
    <faultcode xmlns:app='http://example.org/apps'>
      app:SomeError
    </faultcode>
  </faultcode>
</soap:Fault>

 I admit I don't know XML Schema enough to know the answer
myself.
 This way would be backwards compatible in the simple cases of no
nested faultcodes.
 If this is not possible, I think I'd slightly prefer the
attribute way as well, because I don't see us ever needing to add
structure to the value of faultcode, or additional attributes.
We're keeping the detail element, aren't we? 8-)
 Anyway, if enough people feel the element way is necessary, so
be it, I guess. 8-)
 Thanks for putting this together. 8-)

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Mon, 5 Nov 2001, Martin Gudgin wrote:

 >
 > Here are two proposals for hierarchical fault structures. There are provided
 > in response to issue 130[1] which is about the current hierarchical fault
 > code structure in SOAP. SOAP currently uses a 'dotted' notation for
 > hierarchical fault codes, specifically for the Client and Server 'classes'
 > of fault. This proposal asserts that it is better to use the hierarchical
 > nature of XML to build such fault codes rather than requiring applications
 > to micro-parse element content. Other advantages include;
 >
 > 1. because each faultcode is a QName, there is much better support for
 > ensuring that applications do not define identical fault codes.
 >
 > 2. applications recieving such faults are not required to understand every
 > fault code, they can interpret the higher levels of fault and ignore the
 > more nested fault codes if they do not understand them. This should make
 > processing faults more straightforward as an application can just look at
 > the highest level faultcode to begin with then decide whether it wants to
 > 'drill down' into the more nested information.
 >
 > In addition issue 143[2] requires a resolution of the names Client/Server.
 > This proposal suggests that 'Sender' be substituted for 'Client' and
 > 'Receiver' be substituted for 'Server'. Hence the examples below use
 > 'soap:Receiver'
 >
 >
 >
 > This first example puts the value of the faultcode in a child element with a
 > local name of 'value';
 >
 > <soap:Fault xmlns:soap='http://www.w3.org/2001/09/soap-envelope' >
 >   <faultcode>
 >     <value>soap:Reciever</value>
 >     <faultcode>
 >       <value xmlns:app='http://example.org/apps' >app:SomeError</value>
 >     </faultcode>
 >   </faultcode>
 > </soap:Fault>
 >
 > The schema description looks like this;
 >
 > <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'
 >            xmlns:tns='http://www.w3.org/2001/09/soap-envelope'
 >            targetNamespace='http://www.w3.org/2001/09/soap-envelope' >
 >
 >   <xs:complexType name='faultcodeType' >
 >     <xs:sequence>
 >       <xs:element name='value' type='xsd:QName' />
 >       <xs:element name='faultcode' type='tns:faultcodeType' minOccurs='0' />
 >     </xs:sequence>
 >   </xs:complexType>
 >
 > </xs:schema>
 >
 >
 >
 >
 > This second example puts the value of the fault code in an attribute with a
 > localname of 'value';
 >
 > <soap:Fault xmlns:soap='http://www.w3.org/2001/09/soap-envelope' >
 >   <faultcode value='soap:Reciever' >
 >     <faultcode xmlns:app='http://example.org/apps' value='app:SomeError' />
 >   </faultcode>
 > </soap:Fault>
 >
 >
 > The schema description looks like this;
 >
 > <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'
 >            xmlns:tns='http://www.w3.org/2001/09/soap-envelope'
 >            targetNamespace='http://www.w3.org/2001/09/soap-envelope' >
 >
 >   <xs:complexType name='faultcodeType' >
 >     <xs:sequence>
 >       <xs:element name='faultcode' type='tns:faultcodeType' minOccurs='0' />
 >     </xs:sequence>
 >     <xs:attribute name='value' type='xsd:QName' use='required' />
 >   </xs:complexType>
 >
 > </xs:schema>
 >
 >
 > I have a mild preference for the latter approach.
 >
 >
 > Comments, flames, etc to the usual address
 >
 > Martin Gudgin
 > DevelopMentor
 > http://www.develop.co.uk
 >
 >
 > [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x130
 > [2] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x143
 >

Received on Tuesday, 6 November 2001 04:22:11 UTC