RE: Proposal for hierarchical fault codes

Reviewing this item, I am of the impression that the proposal included
in this mail is the current status of how to deal with multiple fault
codes modulo the DataEncodingUnknown fault being moved out of the core
set and hence dealt with as a "sub" fault? I should say that I like this
proposal!

Is this correct?

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

>-----Original Message-----
>From: Martin Gudgin [mailto:marting@develop.com] 
>Sent: Wednesday, November 07, 2001 10:38
>To: Rich Salz
>Cc: XML Protocol Discussion
>Subject: Re: Proposal for hierarchical fault codes
>
>
>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 Wednesday, 21 November 2001 13:57:36 UTC