[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] FW: Proposal for hierarchical fault codes
Here's the note I mentioned on today's call from Martin Gudgin relating to SOAP fault codes. I think the question of whether to use app-specific parsing of the fault string or use an XML construct would apply equally to SAML. FWIW, I think the former attribute-based design seems pretty simple and appropriate. -- Scott -----Original Message----- From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On Behalf Of Martin Gudgin Sent: Monday, November 05, 2001 5: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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC