How about this definition.  If we move the NSA Id into the main ServiceExceptionType then we can make the downStreamException element a simple assignment.

    <xsd:complexType name="ServiceExceptionType">
        <xsd:sequence>
            <xsd:element name="nsaId"        type="tns:NsaIdType" />
             <xsd:element name="errorId"      type="xsd:string" />
            <xsd:element name="text"           type="xsd:string" />
            <xsd:element name="variables" type="saml:AttributeStatementType" minOccurs="0" />
            <xsd:element name="downStreamException" type="tns:ServiceExceptionType" minOccurs="0" maxOccurs="unbounded" />
        </xsd:sequence>
    </xsd:complexType>

On 2012-03-22, at 8:07 AM, Henrik Thostrup Jensen wrote:

Hi everyone

Following the discussion in Oxford, here is a more concrete proposal for
hierarchical error codes.

Some observations / statements:

* An NSA can choose to present a single error code or a hiarchy of errors.

* A requester might get an error code related to an unknown NSA. This is okay.
 How to handle this is undefined, and is - like most error handly - subject to
 policy.

* We need a timeout error code for to indicate a timeout error.

* We probably need a "downstream error" to indicate that the NSA is functioning
 correctly, but that an unrecoverable error happened downstream. It is also
 possible for an NSA to report a "regular" error code along with an error
 tree, in the case that an error happened both downstream and at the NSA
 itself.

Message Structure:

 <ServiceExceptionType>
   <errorId>
   <text>
   <variables>
   <DownstreamExceptionListType>
     <DownStreamError>
       <NSA>
       <ServiceExceptionType>
     </DownStreamError>
   </DownstreamExceptionListType>
 </ServiceExceptionType>

Comments?


   Best regards, Henrik

Henrik Thostrup Jensen <htj at nordu.net>
Software Developer, NORDUnet

_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg