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:]
Sent: Friday, March 07, 2003 9:02 AM
To:
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
