W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2001

Re: Proposal for hierarchical fault codes

From: Martin Gudgin <marting@develop.com>
Date: Wed, 7 Nov 2001 18:38:11 -0000
Message-ID: <00b301c167bb$5b92fef0$977ba8c0@greyarea>
To: "Rich Salz" <rsalz@zolera.com>
Cc: "XML Protocol Discussion" <xml-dist-app@w3.org>
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, 7 November 2001 13:38:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:04 GMT