[repository schema] Semantic equivalence of fields, components, and groups

[kleihan]

FIX naming conventions still need to consider tag=value encoding, i.e. a field name must not appear more than once in a single FIX message definition. This has led to different field, component, and group names even though they are semantically equivalent, e.g. Parties, NestedParties, Nested2Parties,... (as well as their fields PartyID, NestedPartyID,...). However, not all parties components are semantically equivalent, even if they "look" similar, e.g. Parties vs PartyDetailGrp.

A more complex example is when a component or group is echoed back in the response message whereby the response may have less (but not more) elements that the request. Linking such response elements to the request element allows the validator to ensure that, for example, fields are not added to TrdCapRptAckSideGrp if they are not also in TrdCapRptSideGrp.

An exception list is probably needed for cases where the response has information that cannot be part of the request, e.g. OrderEntryAckGrp vs OrderEntryGrp. The acknowledgement group provides quantity fields (CumQty, LeavesQty,...) that do not apply to order entry. It is still worth capturing the semantic equivalence, similarities in name are only implicit and cannot be automated.

Other examples for semantic equivalence:

• QuoteReqGrp vs QuoteReqRjctGrp
• QuotEntryGrp vs QuotEntryAckGrp

[donmendelson]

@kleihan, your discussion suggests at least two cases:

1. Message elements (fields, components, groups) that have identical semantics but were assigned different tags due to the constraints of tag-value encoding.
2. Message elements that have similar but not identical semantics. The relationship between them may be one of generalization/specialization.

In those two cases, the relationship is between like data structures, e.g. both are repeating groups. There is a third case: where different structures have equivalent semantics. The classic example is ExecBroker was a field in FIX 4.2 but is expressed by a value of PartyRole within a Party group instance in FIX 4.3 and later.

The first case could possibly be handled by adding a simple attribute to the schema. The third case has already been demonstrated with the Concept feature of Orchestra.

The second case could be expressed in a knowledge base using relationships qualified as broader/narrower equivalence. See SKOS definition of those terms. (ISO TC68 SC9 WG1 is trying to work out such a knowledge base for financial industry protocols.)

[kleihan]

The first case is linked to #94 which is about encoded fields equivalent to non-encoded fields. Both are about limitations due to encodings.