Close to 100 NumInGroup fields of FIX Latest still have an abbreviated name in the Orchestra XML file. FIX Latest uses the Orchestra attribute “abbrName” only for FIXML encoding where NumInGroup fields are not present due to the syntax of XML. More than 400 NumInGroup fields of FIX Latest do not use this attribute, starting with fields added after FIX 5.0. [NoOfSecSizes(1177)] is probably the last one (https://fiximate.fixtrading.org/en/FIX.Latest/tag1177.html).
Note that FIXimate intentionally suppresses the display of the value of “abbrName” for fields with datatype NumInGroup but they are present in the Orchestra XML file. Proposal is to remove the attribute “abbrName” from all NumInGroup fields in FIX Latest.
In SecurityListRequest, field SubscriptionRequestType - 263 is described as pertaining to SecurityStatus messages rather than SecurityDefinition/SecurityListUpdateReport messages. It makes more sense to me if the SubscriptionRequestType relates to the Security List dialogue.
@davidcgibbs thanks for pointing this out. Looks like the same field usage comment is being used for four different messages and none of them provide a security status. Most of them were added with FIX 4.3.
A short analysis shows that there is a more serious issue with the request message SecurityTypeRequest(35=v) and the report message SecurityTypes(35=w). The message descriptions are identical but only make sense for the request. The request does not have SubscriptionRequestType(263) but the report message does. It should probably be the other way around but was introduced in FIX 4.3 in this manner, to be analyzed.
The message description for the report is correct up to and including FIX 4.4 and should be as follows:
The Security Type message is used to return a list of security types available from a counterparty or market.
Missing “T” at the start of the message description for StreamAssignmentReport in OrchestraFIXLatest.md
<fixr:annotation>
<fixr:documentation purpose="SYNOPSIS">
he StreamAssignmentReport message is in response to the StreamAssignmentRequest message. It provides information back to the aggregator as to which clients to assign to receive which price stream based on requested CCY pair. This message can be sent unsolicited to the Aggregator from the Price Maker.</fixr:documentation>
</fixr:annotation>
Tablature (specifically md2orchestra) has an issue with a special case of a FIX NumInGroup field that has been implemented as a code set. The field is NoSides(552) and it is being used in four repeating groups (basically trade capture report and cross order messages). FIXimate shows it with a datatype (NumInGroup) and a code set (NoSidesCodeSet). Background is the objective to limit the cardinality of the repeating group to one or two. Trades as well as cross orders have either one or two sides being sent.
The Orchestra XML file of FIX Latest defines the datatype of the code set to NumInGroup. The field itself is defined as a code set (removed non-essential elements for clarity).
<fixr:field abbrName="NoSides" type="NoSidesCodeSet" added="FIX.4.3" name="NoSides" id="552">
<fixr:annotation>
<fixr:documentation purpose="SYNOPSIS">
Number of Side repeating group instances.</fixr:documentation>
</fixr:annotation>
</fixr:field>
<fixr:codeSet name="NoSidesCodeSet" id="552" type="NumInGroup" added="FIX.4.3">
<fixr:code name="OneSide" id="552001" value="1" sort="1" added="FIX.4.3"/>
<fixr:code name="BothSides" id="552002" value="2" sort="2" added="FIX.4.3"/>
</fixr:codeSet>
This causes Tablature to treat NoSides(552) as a normal field reference within the repeating group and raise the error “First group field not NumInGroup datatype” followed by a second error “Unknown group”. The resulting XML file then defines the repeating group as follows:
Trade reporting [Elaboration: The fee charged to recover the cost of trade reporting, e.g. corporate bonds and structured products reported to FINRA TRACE.
should be
The fee charged to recover the cost of trade reporting, e.g. corporate bonds and structured products reported to FINRA TRACE.