- From: Andrew Layman <andrewl@microsoft.com>
- Date: Mon, 5 Nov 2001 10:13:50 -0800
- To: "XML Protocol Discussion" <xml-dist-app@w3.org>
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