- From: Jacek Kopecky <jacek@systinet.com>
- Date: Tue, 6 Nov 2001 10:22:02 +0100 (CET)
- To: Martin Gudgin <marting@develop.com>
- cc: XML Protocol Discussion <xml-dist-app@w3.org>
Gudge, Is there a possibility to make it the following way? <soap:Fault xmlns:soap='http://www.w3.org/2001/09/soap-envelope' > <faultcode> soap:Receiver <faultcode xmlns:app='http://example.org/apps'> app:SomeError </faultcode> </faultcode> </soap:Fault> I admit I don't know XML Schema enough to know the answer myself. This way would be backwards compatible in the simple cases of no nested faultcodes. If this is not possible, I think I'd slightly prefer the attribute way as well, because I don't see us ever needing to add structure to the value of faultcode, or additional attributes. We're keeping the detail element, aren't we? 8-) Anyway, if enough people feel the element way is necessary, so be it, I guess. 8-) Thanks for putting this together. 8-) Jacek Kopecky Senior Architect, Systinet (formerly Idoox) http://www.systinet.com/ On Mon, 5 Nov 2001, Martin Gudgin wrote: > > 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 Tuesday, 6 November 2001 04:22:11 UTC