Imported from previous forum
[ original email was from Henrik Johansson - henrik.johansson@omxgroup.com ]
Hi,
Im am facing some problems with modelling the FIX messages in an object oriented structure in an efficient way:
In FIX it is permissible for fields to be repeated within a repeating group. The field NoXXX is the first field in a repeating group and allows implementations to use this field as a “delimiter” indicating a new repeating group entry (see Fix 4.4 Specification vol 1 page 19.). A delimiter can start different repeating groups. For example is tag 555 NoLegs the delimiter for a repeating group for the IOI message. Tag 555 is also the delimiter for a repeating group for the NewOrderMultiLeg message which is a completely different group.
When modeling these repeating groups there is a problem to decide which repeating group the delimiter refers to, since the groups can be said to have the same signature. One possible way to overcome this problem is that one has to be aware of in which message the group resides. This means that repeating groups are private for each and every message type. Another possible resolution is to look at the fields within the group and from that come to a smart conclusion of what kind of repeating group it is.
Suggested resolution:
If the delimiter fields is unique for each different repeating group it is possible from just looking at the delimiter which group it is and it will be possible for a much simpler implementation. In the example above the NoLegs field could be changed ti NoIOILegs and NoMultilegOrderLegs respectively. Is this something that anyone else think is feasible and therefore might be subject to include in coming releases of the protocol or is it prefferable to stay with the current handling?
Thanks in advance for your opinions,
Henrik
[ original email was from Matt Simpson - msimpson@cme.com ]
Henrik -
Because of the specific nature of repeating groups I would argue that they should be handled on a message-by-message basis. The ‘signature’ for the repeating group could be considered to be message type plus the NoXXX tag. This should point your parser to the correct template for a given repeating group. Using a unique NoXXX tag per group is another possibility but in this case would create a duplicity in the standard; either NoLegs or NoIOILegs, for example. NoLegs couldn’t be retired due the breakage that would result.
One alternative is FIXML! Here all the repeating groups have unique element names which can be referenced as objects in their own right. However, these elements really only have meaning in the context of the messages in which they are used.
Hi,
Im am facing some problems with modelling the FIX messages in an object
oriented structure in an efficient way: In FIX it is permissible for
fields to be repeated within a repeating group. The field NoXXX is the
first field in a repeating group and allows implementations to use this
field as a “delimiter” indicating a new repeating group entry (see Fix
4.4 Specification vol 1 page 19.). A delimiter can start different
repeating groups. For example is tag 555 NoLegs the delimiter for a
repeating group for the IOI message. Tag 555 is also the delimiter for a
repeating group for the NewOrderMultiLeg message which is a completely
different group.When modeling these repeating groups there is a problem to decide which
repeating group the delimiter refers to, since the groups can be said
to have the same signature. One possible way to overcome this problem
is that one has to be aware of in which message the group resides. This
means that repeating groups are private for each and every message
type. Another possible resolution is to look at the fields within the
group and from that come to a smart conclusion of what kind of
repeating group it is.Suggested resolution: If the delimiter fields is unique for each
different repeating group it is possible from just looking at the
delimiter which group it is and it will be possible for a much simpler
implementation. In the example above the NoLegs field could be changed
ti NoIOILegs and NoMultilegOrderLegs respectively. Is this something
that anyone else think is feasible and therefore might be subject to
include in coming releases of the protocol or is it prefferable to stay
with the current handling?Thanks in advance for your opinions, Henrik
[ original email was from Henrik Johansson - henrik.johansson@omxgroup.com ]
Thanks Matt for your reply,
I do understand that it is not easy to retire a field as NoLegs due to the resulting breakage. On the other hand the spec. says that NoLegs is ‘Number of InstrumentLeg repeating group instances’ which is not fully correct for the New Order Multileg message since the following group contains IntrumentLeg plus some other fields (LegQty etc). And yes, there is no problem to point out the correct repeating group since the parser can be context-aware.
What I was aiming for is that I think it would be an advantage, when modelling, that each field would have the same meaning no matter in which message it resides.
Maybe we can rise this issue again for a coming major release (5.0?).
Regards,
Henrik
Henrik -
Because of the specific nature of repeating groups I would argue that
they should be handled on a message-by-message basis. The ‘signature’
for the repeating group could be considered to be message type plus the
NoXXX tag. This should point your parser to the correct template for a
given repeating group. Using a unique NoXXX tag per group is another
possibility but in this case would create a duplicity in the standard;
either NoLegs or NoIOILegs, for example. NoLegs couldn’t be retired due
the breakage that would result.One alternative is FIXML! Here all the repeating groups have unique
element names which can be referenced as objects in their own right.
However, these elements really only have meaning in the context of the
messages in which they are used.Hi,
Im am facing some problems with modelling the FIX messages in an
object oriented structure in an efficient way: In FIX it is
permissible for fields to be repeated within a repeating group. The
field NoXXX is the first field in a repeating group and allows
implementations to use this field as a “delimiter” indicating a new
repeating group entry (see Fix
4.4 Specification vol 1 page 19.). A delimiter can start different
repeating groups. For example is tag 555 NoLegs the delimiter for a
repeating group for the IOI message. Tag 555 is also the delimiter
for a repeating group for the NewOrderMultiLeg message which is a
completely different group.When modeling these repeating groups there is a problem to decide
which repeating group the delimiter refers to, since the groups can be
said to have the same signature. One possible way to overcome this
problem is that one has to be aware of in which message the group
resides. This means that repeating groups are private for each and
every message type. Another possible resolution is to look at the
fields within the group and from that come to a smart conclusion of
what kind of repeating group it is.Suggested resolution: If the delimiter fields is unique for each
different repeating group it is possible from just looking at the
delimiter which group it is and it will be possible for a much simpler
implementation. In the example above the NoLegs field could be changed
ti NoIOILegs and NoMultilegOrderLegs respectively. Is this something
that anyone else think is feasible and therefore might be subject to
include in coming releases of the protocol or is it prefferable to
stay with the current handling?Thanks in advance for your opinions, Henrik