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: Mon, 5 Nov 2001 22:16:21 +0100
Message-ID: <002001c1663f$63a4ebd0$977ba8c0@greyarea>
To: "Andrew Layman" <andrewl@microsoft.com>, "XML Protocol Discussion" <xml-dist-app@w3.org>

----- Original Message ----- 
From: "Andrew Layman" <andrewl@microsoft.com>
To: "XML Protocol Discussion" <xml-dist-app@w3.org>
Sent: Monday, November 05, 2001 7:13 PM
Subject: 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.

OK.

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

Yes, I think that's a reasonable way of expressing it.

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

Err, I don't think so. Default for maxOccurs was 1 last time I looked.

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

Correct :-(

Cheers

Gudge

> 
> -----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 16:19:14 GMT

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