[repository schema] New attribute to identify fields sharing characteristics

[kleihan]

Orchestra support FIX and non-FIX protocols. The FIX Protocol has a naming convention for fields due to its tag=value encoding. Whenever the same field is needed more than once in a single message, it requires to have a different tag number and field name. Examples are:

• Party identifier: PartyID, RootPartyID, NestedPartyID, Nested2PartyID, Nested3PartyID, Nested4PartyID
• Security type: SecurityType, LegSecurityType, UnderlyingSecurityType, DerivativeSecurityType, RelatedSecurityType, InstrumentScopeSecurityType
• Encoded security description: EncodedSecurityDesc, DerivativeEncodedSecurityDesc, InstrumentScopeEncodedSecurityDesc

These fields may or may not have a code set that they share. These fields may have one or more of the alternate field names in a given message. They generally have in common that their abbreviation in the FIXML encoding is identical due to the XML path making them distinguishable from one another.

It is proposed to add an attribute baseFieldId to express such a relationship to support validation and treatment of related fields. For example, they could be required to have the same datatype or code set. One of the fields would be identified as the base field and all others would point to the base field to express a relationship.

Note that some fields would have the attributes nonEncodedFieldId and baseFieldId point to the same field, e.g. like EncodedLegSecurityDesc(622) would have value "207" (field name SecurityDesc) in both cases.

Example: A data field with a datatype as base field for other fields.

<fixr:field name="PartyID" id="448" type="String"/>
<fixr:field name="RootPartyID" id="1117" type="String" baseFieldId="448">
<fixr:field name="NestedPartyID" id="524" type="String" baseFieldId="448">
<fixr:field name="Nested2PartyID" id="757" type="String" baseFieldId="448">
<fixr:field name="Nested3PartyID" id="949" type="String" baseFieldId="448">
<fixr:field name="Nested4PartyID" id="1415" type="String" baseFieldId="448">

Example: A data field with a code set as base field for other fields.

<fixr:field name="SecurityType" id="167" codeSet="SecurityTypeCodeSet"/>
<fixr:field name="LegSecurityType" id="609" codeSet="SecurityTypeCodeSet" baseFieldId="167">
<fixr:field name="UnderlyingSecurityType" id="310" codeSet="SecurityTypeCodeSet" baseFieldId="167">
<fixr:field name="DerivativeSecurityType" id="1249" codeSet="SecurityTypeCodeSet" baseFieldId="167">
<fixr:field name="RelatedSecurityType" id="1652" codeSet="SecurityTypeCodeSet" baseFieldId="167">
<fixr:field name="InstrumentScopeSecurityType" id="1547" codeSet="SecurityTypeCodeSet" baseFieldId="167">

[kleihan]

Needs to be weighed against using the existing capability of Orchestra v1.0 for so-called "instance names" of fields and components.

        <xs:attribute name="instanceName" type="fixr:Name_t">
            <xs:annotation>
                <xs:documentation>Override the field name for this instance, for
                    code generation and the like. Allows more than one instance of a
                    field in a message or component.
                </xs:documentation>
            </xs:annotation>
        </xs:attribute>

        <xs:attribute name="instanceName" type="fixr:ComponentName_t">
            <xs:annotation>
                <xs:documentation>Override the component name for this instance, for
                    code generation and the like. Allows more than one instance of a
                    component in a message.
                </xs:documentation>
            </xs:annotation>
        </xs:attribute>

[donmendelson]

@kleihan, as I understand it, baseFieldId refers to a field with some semantic relationship. On the other hand, instanceName is used to distinguish multiple instances of fields with identical semantics. The attribute could be applied to groups or components as well as individual fields. It was originally requested by Yuval Cohen who used for a non-FIX protocol.

[kleihan]

@donmendelson, thanks for the background. How can we define identical fields/components vs those that are only semantically related? I am thinking of ESMA or SEC-CAT messages where there is a buyer and a seller component. Would these qualify as two identical instances of a single component? In FIX (e.g. TrdCapRptSideGrp) we always need a repeating group, even for just two instances.

A valid question is probably what one would actually do with the information provided by baseFieldId as opposed to using instanceName. Changes to FIX would be quite invasive with the latter, having to change the field tag and name and moving the current field name to instanceName. The upside is that this would reduce the number of FIX fields needed for FIX Latest.