The Orchestra file for FIX Latest is still generated from the Unified Repository. The Orchestra files for FIX 4.2 and FIX 4.4 are supported separately.
Even if I understand that there are no more corrections in FIX.4.4, for the record, the codesets use MultipleValueString instead of MultipleStringValue.
We will need to investigate this and make corrections to the FIX 4.2 and FIX 4.4 representations in Orchestra. The reason is that The distinction between MultipleStringValue and MultipleCharValue was introduced with FIX 5.0. Prior versions only had one such data type and the name was indeed MultipleValueString.
An initial analysis shows that there are multiple errors in the generated Orchestra representations. I have also found tags in FIX Latest such as 286, 291,292, and 529 that have a MultipleChar Value although they are simply “char”. Stay tuned…
FIX Latest seems to be ok, since the tags above (except) had been part of FIX 4.2 and were initially defined as char. They were changed to MultipleValueString with FIX 4.3 and to MultipleCharValue with FIX 5.0. So it looks like the issues are limited to the Orchestra representations for FIX 4.2 and FIX 4.4 in GitHub and we will make changes to get them in sync with the original data type definitions.
After reviewing Orchestra files further, here are some additional comments.
About FIX.4.4 Orchestra file:
- value 12 is missing for OrdRejReasonCodeSet (it is appended in the description of value 11 instead),
- many fields specify a datatype instead of a codeset (especially fields with a description like “same values as …”, for example, 456, 562, 524, 525, 564 587, 606, 761),
- tag 139 specifies the type char instead of String.
About FIX.4.4 and FIX.Latest Orchestra files:
-
What about repeating group field presence requirement in Orchestra?
In repeating group definitions, the first field reference does not specify presence=“required” and its description usually mentions “required if No… > 0”.
In my opinion, the first field should be set as required in the context of the repeating group (then the repeating group reference specifies its own presence, optional or required). What do you think?
Consequently other required fields of repeating groups should specify presence=“required” (for example, 456, 459, 217, 447, 452, 525, 538, 139). -
"Other values may be used by mutual agreement of the counterparties"
Many fields specify this in their description but don’t have an unionDataType=“String”. For example, 167, 233, 234, 1317, 1940, 1941, 1979, 2015, 2016, 2069, 2079, 2083, 2192, 2634, 40922.
Also tag 477 specifies unionDataType=“Reserved100Plus” but its description specifies “Values above 1000”. -
NumInGroup datatype
It’s not clear if it accepts zero (I think it should). Its description is “Value must be positive”.
Also note that there is an error in the Orchestra specification: https://www.fixtrading.org/standards/fix-orchestra-online/. In “Conditionally required field”, there is an example which states “presence=“conditional”” although “conditional” is not a valid value according to the previous “presence” definition.
Zero is neither positive nor negative, so if the value has to be positive it has to be larger than zero. But I have to admit it could be stated more explicitly.
Why do you think the field should accept zero? As far as I know using zero for NumInGroup is discouraged.
See here for current rules of repeating groups.
- The NumInGroup field is required and must be larger than zero if the repeating group is required, or if the repeating group is optional and the message contains one or more instances for that repeating group.
The current approach (since day 1 of FIX actually) is to define “required” for elements of repeating groups in the context of the entire message. This has to do with the fact that a tag=value message does not have a nested wire structure, it is simply a list of fields. I agree that this approach should be revisited in the context of Orchestra where we can express conditionally required fields. It should be agnostic to the encoding. Currently, the first field of a repeating group typically has a usage comment, e.g. “Required if NoPartyIDs(453) > 0.” It is not really machine-readable.
In FIX.4.4, for message AB, NoLegs was required with this description:
In FIX.Latest, it seems that NoLegs is now optional.
1 Like
OK, did not know that. But good that FIX.Latest rectified this.