An email that came into the programme office:
I was just looking at the MsgType=AS in FIXimate and noticed the repeating group NoAllocs is followed by AllocAccount, but AllocAccount is not marked as ‘required’. For a repeating group the tag that follows the count is always required since it is used as the delimiter between each repeating block in that group, so AllocAccount should be marked as required.
I don’t know if that is a restriction of Fiximate or just left out because it is known that the first tag in a repeating group acts as delimiter: but this is true for every other repeating group in Fiximate too. E.g. NoPartyIDs.
But the comment description always is along the lines of: “Required if NoPartyIDs(453) > 0.”
It’s definitely a mess handling parsing when people don’t provide the first spec-tag in the group.
If you enforce ordering you can work out group segregation by the first “out of order” tag.
Or you can ignore the “spec-first tag” and use the first actually provided tag after the count tag and wait for that to reappear.
But it is way easier if people do treat the first tag as required.
The field usage description of AllocAccount(79) in the AllocationReport(35=AS) message reads:
Required if NoAllocs(78) > 0.
Must be first field in repeating group.
Note that this is technically only the case for tag=value encoding. However, FIX repeating groups are designed in a way that puts the key element(s) at the beginning that are required semantically for the content of the group to make sense. An allocation without an account does not really make sense. 
The current logic of FIXimate is that the column “Req’d” is only set to “Y” if a field is required on every message. It is hence not set to “Y” if the repeating group itself is not required. The text then expresses a conditional requirement based on the presence of the NumInGroup field (only works for tag=value as e.g. FIXML does not have that field).
I would be interested to hear from users whether it makes sense to change this display logic. Elements of a repeating group would then be set to Req’d=“Y” if they are required for every instance of the group.
Thanks,
Hanno.
GTC co-chair
As @gtcpm pointed out the text is there but it is a bit buried. It needs to be the first thing in the field usage.
Historically repeating group components have their fields Req’d=N within the component definition. Whether the component is required in a message or not depends on the Req’d in that message. In Vol. 1 of the last published pdf spec, we have this text at the bottom of the repeating group definitions at the time (an example): " **** = Required status should match “Req’d” setting for component block in message definition* "
I would find it confusing to see, for example, Parties marked as Req’d=N in a message but when expanding the component in that msg in FIXimate it shows the component fields Req’d=Y. That’s my opinion.
Req’d=Y is used to express an unconditional requirement. This is not the case for repeating groups as there is a condition that needs to be me for a field to be required. The condition is the existence of an instance of the group. There are many other types of conditions related to the presence of absence of a field and/or value. Orchestra provides the ability to define such conditions.
The distinction between conditionally and unconditionally required elements of a message can be made by using a third letter in addition to Y and N. The letter “C” would stand for the fact that there is some condition behind the presence rule. The usage description can then explain the condition. Today, we only have the explaining text and no machine-readable version of the rule behind it. The objective is to enhance the Orchestra representation of FIX Latest by using the Orchestra capabilities to express presence rules in a machine-readable form.
If “C” is introduced for such cases to signal there is a condition that needs to be met, then it would be clearer, I just don’t want to use “Y” in the case of examples in this thread.