RE: Proposal for hierarchical fault codes

1.	XML attributes cannot have structure nor can they themselves
have attributes.  This makes elements more amenable to future extension.
For that reason, I'd favor using elements, since they give you more
flexibility to extend information content in the future without breaking
the structure.

2.	You imply by your example but don't state that the child
<faultcode> elements represent elaboration of their parent. Correct?

3.	You allow multiple child <faultcode> elements.  These are meant
to be disjoint elaborations of their parent?  Is order in any way
significant?

4.	I think you've misspelled "receiver" in some examples.

-----Original Message-----
From: Martin Gudgin [mailto:marting@develop.com] 
Sent: Monday, November 05, 2001 2:47 AM
To: XML Protocol Discussion
Subject: Proposal for hierarchical fault codes


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 Monday, 5 November 2001 13:14:25 UTC