Imported from previous forum
In an actual FIX message can the fields of a component block be
interspersed with other fields of its containing message?
The FIX 4.3 specification states:
"Except where noted, fields within a message can be defined in any
sequence (Relative position of a field within a message is
inconsequential.)"
So the only situation where component block fields must be grouped in
the order shown in the specification is when they are used as part of a
repeating group as the specification states:
"Fields within repeating data groups must be specified in the order that
the fields are specified in the message definition within the FIX
specification document."
So the answer to my question seems to be that yes (except where used in
a repeating group) - the fields of a component block maybe interspersed
with other fields of the same message.
Why am I asking a question that I seem to know the answer to? Because I
don’t like the answer!
I’m modeling FIX messages (for IBM’s WebSphere MQSeries Integrator
product) and I’d like to model a FIX message as an unordered set
containing simple fields, repeating groups (which are modeled as ordered
sets) and component blocks. But if the fields within a component block
can be interspersed with fields of the containing message then the
message and the contained component block can’t be modeled as separate
entities.
So while I’d like to model a message containing a component block as:
Message (unordered set)
|
± A (simple field)
|
± B (component block)
|
± C (simple field)
Component Block (unordered set)
|
± X (simple field)
|
± Y (simple field)
|
± Z (simple field)
This model implies that in an actual message I can find A, B and C in
any order but if I hit an X, Y or Z then all other fields of B must be
grouped (in any order) with it - they cannot be interspersed with A and
C. This is contrary to the specification so I have to model a message
like so, lossing the fact that X, Y and Z form a logical group:
Message (unordered set)
|
± A (simple field)
|
± X (simple field)
|
± Y (simple field)
|
± Z (simple field)
|
± C (simple field)
You may say tough luck but I’d be interested in hearing any comments.
Thanks - yours,
George.
WebSphere MQSeries Integrator Adapter Development - IBM Dublin
PS the model I’m creating is used to parse actual incoming messages but
the structure generated as a result of the parse must be capable of
maintaining the order of the fields as they appeared in the actual
original message, so the output data structure for a message will be
some form of list rather than a set.
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
George,
You have answered your own question. As of FIX 4.3, non-repeating component blocks are not required to be in sequence order or adjacent - they can be interspersed with other non-repeating elements.
Should the component block contain a repeating group, such as in the case of the Party Block, ordering used to only apply to the first element of the repeating group after the NoXXXX (number of) field as with any other FIX repeating group.
With FIX 4.3, the specification has been tightened up, as you point out, to require that the fields within the repeating group be specified in the order that they appear within the specification.
So, unfortunately, the answer you provided that you did not want is the correct answer 
If you are developing an application that may require communication with other vendor or customer products (likely), I would strongly encourage you not to enforce sequencing where the specification does not require it. I would even encourage you to build your parser in such a way as to allow it to support pre-FIX 4.3 repeating group rules in order to provide maximum flexibility and to minimize problems integrating with other systems down the road.
Jim
> In an actual FIX message can the fields of a component block be
> interspersed with other fields of its containing message?
>
> The FIX 4.3 specification states:
>
> “Except where noted, fields within a message can be defined in any
> sequence (Relative position of a field within a message is
> inconsequential.)”
>
> So the only situation where component block fields must be grouped in
> the order shown in the specification is when they are used as part of a
> repeating group as the specification states:
>
> “Fields within repeating data groups must be specified in the order that
> the fields are specified in the message definition within the FIX
> specification document.”
>
> So the answer to my question seems to be that yes (except where used in
> a repeating group) - the fields of a component block maybe interspersed
> with other fields of the same message.
>
> Why am I asking a question that I seem to know the answer to? Because I
> don’t like the answer!
>
> I’m modeling FIX messages (for IBM’s WebSphere MQSeries Integrator
> product) and I’d like to model a FIX message as an unordered set
> containing simple fields, repeating groups (which are modeled as ordered
> sets) and component blocks. But if the fields within a component block
> can be interspersed with fields of the containing message then the
> message and the contained component block can’t be modeled as separate
> entities.
>
> So while I’d like to model a message containing a component block as:
>
> Message (unordered set)
> |
> ± A (simple field)
> |
> ± B (component block)
> |
> ± C (simple field)
>
> Component Block (unordered set)
> |
> ± X (simple field)
> |
> ± Y (simple field)
> |
> ± Z (simple field)
>
> This model implies that in an actual message I can find A, B and C in
> any order but if I hit an X, Y or Z then all other fields of B must be
> grouped (in any order) with it - they cannot be interspersed with A and
> C. This is contrary to the specification so I have to model a message
> like so, lossing the fact that X, Y and Z form a logical group:
>
> Message (unordered set)
> |
> ± A (simple field)
> |
> ± X (simple field)
> |
> ± Y (simple field)
> |
> ± Z (simple field)
> |
> ± C (simple field)
>
> You may say tough luck but I’d be interested in hearing any comments.
>
> Thanks - yours,
>
>
> George.
>
> WebSphere MQSeries Integrator Adapter Development - IBM Dublin
>
> PS the model I’m creating is used to parse actual incoming messages but
> the structure generated as a result of the parse must be capable of
> maintaining the order of the fields as they appeared in the actual
> original message, so the output data structure for a message will be
> some form of list rather than a set.
>
>