(I am sorry that, indeed, someone has asked the same question before (check this: repeating groups and field order) but I can’t see the answer – can somebody shed a light on this?)
For the repeating group, my understanding is that the ordering of fields inside a repeating group must be matched the ordering defined in the specs. However, I am a little bit wondering if this requirement is also applicable to those fields in a component block. (I personally think that the all fields, including the fields in the component block, inside a repeating group must be matched the ordering defined in the specs…)
For example, in the TrdCapRptSideGrp, we have the CommissionData component and also assume we define the ordering of 12/13/479 is as below (in our specs). I will like to know if the receiving ordering is 13, 12 and then 479, will we accept or reject it?
The spec is defined as:
54=xxx
…
(CommissionData component block here)
12=xxx
13=xxx
479=xxx
(CommissionData component block here)
…
Like if we receive the following - accept or reject?
54=xxx
…
(CommissionData component block here)
13=xxx
12=xxx
479=xxx
(CommissionData component block here)
…
Thanks,
Robert
The ordering of fields inside repeating groups only applies to tagvalue encoding and is needed for proper parsing. It does not apply to components. In repeating groups, it is needed to separate the instances from one another. Also, a field that is not in the repeating group marks the end of the group.
See https://www.fixtrading.org/standards/tagvalue-online#components in the online FIX spec for tagvalue:
The FIX tagvalue encoding does not represent component boundaries in the encoding. Any component boundary is lost during encoding. Further, FIX tagvalue encoding does not require the collection of fields to be ordered, and does not enforce component boundaries around the fields in the encoding.
The ordering of fields inside repeating groups only applies to tagvalue encoding and is needed for proper parsing. It does not apply to components
If I understood correctly the question was about components inside of repeating groups. I assume the component is simply put (meaning fields are “copied” into) inside the repeating group, so shouldn’t the ordering also be enforced on the fields of the component then?
Thanks,
Chris.
Thanks hanno. I do have difficulty to understand the following - I am sorry that I cannot see the relationship between the component block and the repeating group(i.e. the requirement of field ordering).
The FIX tagvalue encoding does not represent component boundaries in the encoding. Any component boundary is lost during encoding. Further, FIX tagvalue encoding does not require the collection of fields to be ordered, and does not enforce component boundaries around the fields in the encoding.
As for my question, if the fields in a component block inside a repeating group can be out of order, my further question is that can we move one field from a component block outside it, like
54=xxx**(This is a repeating group)**
…
(CommissionData component block here)
13=xxx
479=xxx
(CommissionData component block here)
other_tag_here=xxx
12=xxx
…
Thanks,
Robert
Thanks, Chris.
Yes, my question is like:
(A)
54=xxx…12=xxx13=xxx479=xxx…
^
Repeating group
(B)
54=xxx…13=xxx12=xxx479=xxx…
^
Repeating group
(A) Is the ordering we defined in our spec, where 12/13/479 are the fields in a component block.
(B) Is the received message. Accept or reject it?
Regards,
robert
@robertlau, sorry for missing the bit about TrdCapRptSideGrp and thanks, @christophjohn for pointing that out. If a component is inside a repeating group then the rule also applies to the fields of the component. On the wire for tagvalue format they are just fields, there are no component boundaries. Hence they need to be treated just like fields inside repeating groups that are not also in a component. You cannot move component fields around if the component is part of a repeating group. This is only possible for component on the root level of a message or for components nested in other components.
The field ordering for components inside repeating groups also means, for example, that for an Instrument component that is the first element of a repeating group (e.g. InstrmtGrp), the field Symbol(55) becomes a required field and you need to set it to “[N/A]” if you do not have a real value for Symbol(55).
1 Like
Got it. Your explanation will make the FIX parser happier. Thanks hanno.klein.
1 Like