OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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