Re: Proposal for hierarchical fault codes

Gudge, how would we report RPC faults? Would it have to be
something like (I'm using your latest flat approach, but it can
be rewritten into any other)

<faultcode>
  <value>env:Client</value>
  <sub>rpc:MethodNotFound</sub>
</faultcode>

Or would the enum contain all the faults defined by our spec?
This would be awkward since RPC is an optional part, so probably
the former is the way. This could be a nice demonstration in-spec
of how the faultcodes are meant to work. 8-)

                   Jacek Kopecky

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



On Wed, 7 Nov 2001, Martin Gudgin wrote:

 > Thinking about it the flat approach some more, it turns out the schema that
 > restricts the first value to a enumeration of QNames is impossible to write
 > if all the siblings have the same name. This is because it is not legal in
 > XML Schema to map the same element name in a given context to more than one
 > type. Using one of the hierarchical approaches would fix this. Alternatively
 > we could define a schema 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:simpleType name='faultcodeenum'>
 >      <xs:restriction base='xs:QName'>
 >        <xs:enumeration value='tns:DataEncodingUnknown' />
 >        <xs:enumeration value='tns:MustUnderstand' />
 >        <xs:enumeration value='tns:VersionMismatch' />
 >        <xs:enumeration value='tns:Receiver' />
 >        <xs:enumeration value='tns:Sender/>
 >      </xs:restriction>
 >    </xs:simpleType>
 >
 >    <xs:complexType name='faultcodeType' >
 >      <xs:sequence>
 >        <xs:element name='value' type='tns:faultcodeenum' />
 >        <xs:element name='sub' type='xsd:QName' minOccurs='0'
 > maxOccurs='unbounded' />
 >      </xs:sequence>
 >    </xs:complexType>
 >
 > </xs:schema>
 >
 > which gives an instance like;
 >
 > <faultcode>
 >   <value>soap:Reciever</value>
 >   <sub xmlns:app='http://example.org/apps' >app:SomeError</sub>
 > </faultcode>
 >
 >
 > The schema for the hierarchical approach ( the attribute form in this case )
 > would look 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:simpleType name='faultcodeenum'>
 >      <xs:restriction base='xs:QName'>
 >        <xs:enumeration value='tns:DataEncodingUnknown' />
 >        <xs:enumeration value='tns:MustUnderstand' />
 >        <xs:enumeration value='tns:VersionMismatch' />
 >        <xs:enumeration value='tns:Receiver' />
 >        <xs:enumeration value='tns:Sender/>
 >      </xs:restriction>
 >    </xs:simpleType>
 >
 >   <xs:complexType name='rootfaultcodeType' >
 >     <xs:sequence>
 >       <xs:element name='faultcode' type='tns:faultcodeType' minOccurs='0' />
 >     </xs:sequence>
 >     <xs:attribute name='value' type='tns:faultcodeenum' use='required' />
 >   </xs:complexType>
 >
 >   <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>
 >
 > with an instance of;
 >
 > <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>
 >
 >
 > Regards
 >
 > Gudge
 >
 > ----- Original Message -----
 > From: "Rich Salz" <rsalz@zolera.com>
 > To: "Martin Gudgin" <marting@develop.com>
 > Cc: "XML Protocol Discussion" <xml-dist-app@w3.org>
 > Sent: Wednesday, November 07, 2001 12:30 PM
 > Subject: Re: Proposal for hierarchical fault codes
 >
 >
 > > >    <faultcode>
 > > >      <value>soap:Reciever</value>
 > > >      <value xmlns:app='http://example.org/apps' >app:SomeError</value>
 > > >    </faultcode>
 > >
 > > > This doesn't imply a hierarchy to me but rather that all the fault codes
 > are
 > > > of equal 'importance'. But I can see the argument that the order of the
 > > > siblings determines importance.
 > >
 > > Right, it's a slight shift of emphasis.
 > >
 > > The sender may now include multiple fault values that provide differing
 > > levels of specificity or other description.  The receiver scans through
 > > the list looking for a QNAME it understands.
 > >
 > > As for schema definition, I'd actually consider tweaking it so that the
 > > first value element must be from the standard-specificed enumerated list
 > > of values.  Subsequent optional value elements may provide more detail
 > > for the receiver.
 > > /r$
 > >
 > > --
 > > Zolera Systems, Securing web services (XML, SOAP, Signatures,
 > > Encryption)
 > > http://www.zolera.com
 >

Received on Thursday, 8 November 2001 03:11:45 UTC