RFC 2119 is used in the Orchestra Technical Specification as well as for annotations of the presence attribute in the schema (see RC3 schema snippet below).
It is proposed to add two new values "recommended" and "deprecated" to express that a group, component or field referenced in the definition of a message, group or component SHOULD or SHOULD NOT be present. It is further proposed to add an attribute "presenceAction" to define the action to be taken when the validation of the presence attribute fails.
The main use case is to identify fields that are required by the recipient but should not necessarily cause the entire message of the sender to be rejected. There may be a process in place to obtain the missing information from the sender. This could be an automated lookup (causing a delay) or even a manual process that prevents straight-through-processing. Presence attribute violations can be tracked over time to assess the quality of the data provided by the sender.
A new value "deprecated" would support the evolution of an interface over time. Orchestra already supports pedigree information to capture the version as of which an element was deprecated. The element may or may not continue to be supported but this cannot be expressed in Orchestra in a machine-readable way. This is the main use case for the new attribute "presenceAction", which could take values such as "rejection", "warning" or "none". Deprecated elements may initially only cause a warning and eventually change to a rejection in a later version. That is semantically richer than changing it to "forbidden", which should only be used for elements that were never allowed, e.g. an equity instrument scenario must never have FIX field PutOrCall(201).
The actions also apply to the existing values of presence, e.g. a missing field defined as “required” in a message could lead to a rejection or warning or no action (i.e., ignoring the violation). Some values only make sense with a subset of the actions, e.g. optional fields must not have "rejection" as an action. The following table gives a possible recommendation for invalid combinations (N/A).
| |
rejection |
warning |
none |
| optional |
N/A |
N/A |
|
| recommended |
N/A |
|
|
| required |
|
N/A |
N/A |
| forbidden |
|
N/A |
N/A |
| ignored |
N/A |
|
|
| constant |
|
|
|
| deprecated |
|
|
|
<xs:simpleType name="presence_t">
<xs:restriction base="xs:string">
<xs:enumeration value="optional">
<xs:annotation>
<xs:documentation>The field or component MAY be present; it may be conditionally required based on a rule.</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="required">
<xs:annotation>
<xs:documentation>The field or component MUST be present.</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="forbidden">
<xs:annotation>
<xs:documentation>The field or component MUST NOT be present.</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="ignored">
<xs:annotation>
<xs:documentation>The field or component MAY be present but is not validated.</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="constant">
<xs:annotation>
<xs:documentation>The field has a constant value; in some encodings it need not be sent on the wire.</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
RFC 2119 is used in the Orchestra Technical Specification as well as for annotations of the
presenceattribute in the schema (see RC3 schema snippet below).It is proposed to add two new values "recommended" and "deprecated" to express that a group, component or field referenced in the definition of a message, group or component SHOULD or SHOULD NOT be present. It is further proposed to add an attribute "presenceAction" to define the action to be taken when the validation of the
presenceattribute fails.The main use case is to identify fields that are required by the recipient but should not necessarily cause the entire message of the sender to be rejected. There may be a process in place to obtain the missing information from the sender. This could be an automated lookup (causing a delay) or even a manual process that prevents straight-through-processing. Presence attribute violations can be tracked over time to assess the quality of the data provided by the sender.
A new value "deprecated" would support the evolution of an interface over time. Orchestra already supports pedigree information to capture the version as of which an element was deprecated. The element may or may not continue to be supported but this cannot be expressed in Orchestra in a machine-readable way. This is the main use case for the new attribute "presenceAction", which could take values such as "rejection", "warning" or "none". Deprecated elements may initially only cause a warning and eventually change to a rejection in a later version. That is semantically richer than changing it to "forbidden", which should only be used for elements that were never allowed, e.g. an equity instrument scenario must never have FIX field PutOrCall(201).
The actions also apply to the existing values of
presence, e.g. a missing field defined as “required” in a message could lead to a rejection or warning or no action (i.e., ignoring the violation). Some values only make sense with a subset of the actions, e.g. optional fields must not have "rejection" as an action. The following table gives a possible recommendation for invalid combinations (N/A).