RE: [provision] Results codes...

["Cohen, Doron" <Doron_Cohen@bmc.com>]

I agree we need more error codes, however I believe it would be clearer to
separate the codes to a result code and a reason code where the result code
clearly indicates the failure or success while the reason code express in
more details the core issue of the failure. Otherwise we have to define much
better what each return code means in terms of the resulted execution of the
request .

I am also not sure about the generalError since I do not understand what
added value it carries compared with the existing failure code. For the sake
of the extensibility , I prefer an approach that allocates an extended set
of reason codes (in the line of separating the result and reason code)  to
be vendor specific codes. 

Doron

Doron Cohen
Chief Architect, Security Line of Business
BMC Software


-----Original Message-----
From: Yoav Kirsch [mailto:Yoav.Kirsch@businesslayers.com
<mailto:Yoav.Kirsch@businesslayers.com> ] 
Sent: Friday, March 07, 2003 4:09 PM
To: 'Jeff Bohren'; provision@lists.oasis-open.org
Subject: RE: [provision] Results codes...


I agree. We need as many error codes as possible.
We also need a general error 
 
generalError - place holder for the unknown error
 
 
Yoav Kirsch
Director, Applications Development
Business Layers
 
-----Original Message-----
From: Jeff Bohren [mailto:jbohren@opennetwork.com
<mailto:jbohren@opennetwork.com> ] 
Sent: Friday, March 07, 2003 9:02 AM
To: provision@lists.oasis-open.org
Subject: [provision] Results codes...
 
The current definition for results codes for an SPML request is:
 
            <xsd:simpleType name="ResultCode">
                        <xsd:restriction base="xsd:string">
                                    <xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#success"/>
                                    <xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#failure"/>
                                    <xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#pending"/>
                        </xsd:restriction>
            </xsd:simpleType>
 
The failure enumeration is a catch all failure, but we probably need more
granular failure result codes. I would like to expand that list to include:
 
malformedRequest
unsupportedOperation
unsupportedIdentifierType
noSuchIdentifier
 
 
Where these error codes mean the following
 
malformedRequest - request is valid in terms for the SPML schema, but does
not conform to normative SPML specifications
 
unsupportedOperation - request is made for an operation not supported by the
SPML service
 
unsupportedIdentifierType - identifier type is specified that is not
supported by the SPML service
 
noSuchIdentifier - request is made for an identifier that does not exist
 
 
 
Darran, could you add a motion for Mondays agenda to expand the results
types to include these four additional types?
 
 
 
 
 
 
 
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 
 

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>