Imported from previous forum
[ original email was from John Hardman - yiq12@dial.pipex.com ]
The FIX 4.2 specification says that fields can appear in pretty much any order except for specific cases (e.g. within repeating groups).
Is is true (or should it be) that where a count appears of how many instances of a repeating group there are that this count should appear immediately before the first instance of the repeated group ?
For example, in the Allocation message (MsgType = J) should NoOrders (field tag = 73) appear immediately before ClOrdId (field tag = 11), should NoExecs (field tag = 124) appear immediately before LastShares (field tag = 32), should NoAllocs (field tag = 78) appear immediately before AllocAccount (field tag = 79), and should NoMiscFee (field tag = 136) appear immediately before MiscFeeAmt (field tag = 137) ?
On a more general note (very useful for writing generic parsing and validation code) is it true that there cannot be two unrelated nested groups at the same depth one after the other without an intervening field at a shallower level of nesting ?
Many thanks in advance for any help,
John Hardman.
The "count" field for a repeating group should immediately precede the repeating group contents. Every message definition or example in the FIX spec represent it this way, however, it is currently not explicitly stated as such.
The "count" fields are similar to the "length" fields for fields of data type "data" (e.g. SecureDataLen and SecureData) in which the spec does state "Data fields are always immediately preceded by a length field".
> The FIX 4.2 specification says that fields can appear in pretty much any order except for specific cases (e.g. within repeating groups).
>
> Is is true (or should it be) that where a count appears of how many instances of a repeating group there are that this count should appear immediately before the first instance of the repeated group ?
>
> For example, in the Allocation message (MsgType = J) should NoOrders (field tag = 73) appear immediately before ClOrdId (field tag = 11), should NoExecs (field tag = 124) appear immediately before LastShares (field tag = 32), should NoAllocs (field tag = 78) appear immediately before AllocAccount (field tag = 79), and should NoMiscFee (field tag = 136) appear immediately before MiscFeeAmt (field tag = 137) ?
>
> On a more general note (very useful for writing generic parsing and validation code) is it true that there cannot be two unrelated nested groups at the same depth one after the other without an intervening field at a shallower level of nesting ?
>
> Many thanks in advance for any help,
>
> John Hardman.
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> On a more general note (very useful for writing generic parsing and validation code) is it true that there cannot be two unrelated nested groups at the same depth one after the other without an intervening field at a shallower level of nesting ?
I’m not sure what you mean here.
Several FIX messages have repeating groups at the same level of nesting. For instance, in Market Data Request, one could say:
NoMDEntryTypes=2
MDEntryType=0
MDEntryType=1
NoRelatedSym=2
Symbol=MSFT
Symbol=CSCO
Where in this case there are two different repeating groups, one of MDEntryTypes and one of Symbols. They are at the same level (the root of the application message).
I think the key is that the answer to the first which was that the "number" field for the repeating group should immediately precede the repeating group contents themselves "solves" this problem/question. In your example, NoRelatedSym appears between the MDEntryType and RelatedSym repeating group contents.
> > On a more general note (very useful for writing generic parsing and validation code) is it true that there cannot be two unrelated nested groups at the same depth one after the other without an intervening field at a shallower level of nesting ?
>
> I’m not sure what you mean here.
>
> Several FIX messages have repeating groups at the same level of nesting. For instance, in Market Data Request, one could say:
>
> NoMDEntryTypes=2
> MDEntryType=0
> MDEntryType=1
> NoRelatedSym=2
> Symbol=MSFT
> Symbol=CSCO
>
> Where in this case there are two different repeating groups, one of MDEntryTypes and one of Symbols. They are at the same level (the root of the application message).
>
>