Imported from previous forum
Can a field within a message be repeated twice? For example two ClOrdID fields within the same message. I am not referring to repeating fields such as multiple ClOrdId’s within the NoOrders fields in an Allocation message. It doesn’t seem logicol to do so, but the spec seems a bit vague.
thanks
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Can a field within a message be repeated twice? For example two ClOrdID fields within the same message. I am not referring to repeating fields such as multiple ClOrdId’s within the NoOrders fields in an Allocation message. It doesn’t seem logicol to do so, but the spec seems a bit vague.
I believe the language of the spec specifically allows it, but common practice forbids its useage in most cases.
I could conceivably see, for example, repeating a field like Text in messages where it is not part of a repeating group. But I cannot see a business reason to repeat ClOrdID, and doing so opens up significant possibilities for confusion.
[ original email was from Francesc Prats - fprats@meff.com ]
> > Can a field within a message be repeated twice? For example two ClOrdID fields within the same message. I am not referring to repeating fields such as multiple ClOrdId’s within the NoOrders fields in an Allocation message. It doesn’t seem logicol to do so, but the spec seems a bit vague.
>
> I believe the language of the spec specifically allows it, but common practice forbids its useage in most cases.
>
> I could conceivably see, for example, repeating a field like Text in messages where it is not part of a repeating group. But I cannot see a business reason to repeat ClOrdID, and doing so opens up significant possibilities for confusion.
>
>
according to the FIX 4.3 specs, I think you can’t repeat a tag out of a repeating group and, if this happened, the message must be rejected with a “Session-level Reject” message with tag 373 (SessionRejectReason) = “13” (Tag appears more than once).
What I have said have been appeared in FIX 4.3 (but not in FIX 4.2 and earlier versions). Seeing the subject, FIX 4.0, I think that the conclusion must be the same (rejecting the message) using an user-defined tag to say the reject reason or using tag 373 with value “0” (Invalid tag number.
Any thoughts?
Specifying the same tag twice (when not part of a repeating group) results in significant parsing challenges. The Tech Committee would consider that an error in the spec. The language within FIX 4.3 was amended to clarify this point and we have Errata’d those types of issues in FIX 4.2 and 4.3.
As far as I can recall, the only potential exceptions documented to the contrary are a couple of the Standard Header fields which are denoted as being able to appear both within and outside of SecureData when using encryption, however, the spec says to use the value within SecureData if they’re not the same.
> > > Can a field within a message be repeated twice? For example two ClOrdID fields within the same message. I am not referring to repeating fields such as multiple ClOrdId’s within the NoOrders fields in an Allocation message. It doesn’t seem logicol to do so, but the spec seems a bit vague.
> >
> > I believe the language of the spec specifically allows it, but common practice forbids its useage in most cases.
> >
> > I could conceivably see, for example, repeating a field like Text in messages where it is not part of a repeating group. But I cannot see a business reason to repeat ClOrdID, and doing so opens up significant possibilities for confusion.
> >
> >
> according to the FIX 4.3 specs, I think you can’t repeat a tag out of a repeating group and, if this happened, the message must be rejected with a “Session-level Reject” message with tag 373 (SessionRejectReason) = “13” (Tag appears more than once).
> What I have said have been appeared in FIX 4.3 (but not in FIX 4.2 and earlier versions). Seeing the subject, FIX 4.0, I think that the conclusion must be the same (rejecting the message) using an user-defined tag to say the reject reason or using tag 373 with value “0” (Invalid tag number.
> Any thoughts?
>