OARIS — Request_ack_type/error_reason_type/denial_reason_type needs more identifying information

These are generic fields used to describe responses following requests. They are published asynchronously to the original request – the request and response are associated with each other using a common request ID found in each.
The response information is a free-text String. Though this can represent useful information to convey directly to an operator, it does not allow a specific field to be identified at fault (the original request may be composed of a number of fields). Also, there may be several fields at fault.
I would suggest the following –
o Allow multiple denial/error reason fields to be associated with the response rather than just one
o Add an identifier to the field, which can be a generic string. The identity will be appropriate to the original response e.g. the parameter name at fault with appropriate namespacing, or a null value if the error message refers to the whole request in general (e.g. loss of communication). The format of the error identifier should be defined in the description of the request service/topic.
(From Nick Davies - Thales UK)

Allow multiple error reasons with parameter identifier

A rejecting request_ack should be able to refer to the particular fields that are at fault and to be able to identify multiple discrete errors (for requests with sets of parameters in particular - e.g. Manage Subsystem Parameters and Manage Transmission Sectors).
A new struct class denial_type with attributes for the existing reason and zero-to-many parameter reference (new typedef of string) should be added to the model. request_ack_type then composes zero-to-many of these.
<<idlStruct>> denial_type
+ reason : denial_reason_type
+ related_parameter : parameter_reference_type [0..*]

<<idlTypedef>> parameter_reference_type
(generalizes string)
Tag: Length = 64

compostion of denial_type by request_ack_type
denial_type role: name = element, multiplicity 0..*