Imported from previous forum
[ original email was from Joseph Horowitz - joey@aegisoft.com ]
Originally posted by Benedict Zoe of Bloomberg ( http://www.fixprotocol.org/cgi-bin/BBS.cgi?menu=712&board=3&message=26&thread=26 ), I think this idea is worth repeating (small pun intended).
May I suggest adding a new EndRepeatingGroup tag, to indicate the end of a repeating group. Utilizing such a tag would provide several advantages:
-
Eliminate the restriction: "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." - since it would now be clear where the repeating group ends and the base message, or outer repeating group, continues.
-
Eliminate the ambiguity, or error, that can occur in the rare case when the same tag is defined within the middle of a repeating group and within the base message, or outer repeating group.
-
Make the use of Custom Tags within a repeating group unambiguous and permissible. As the specification stands today, there is no clear definition where a Custom Tag may be placed within a repeating group. The problem becomes more difficult when parsing the last repeated instance.
Although this change would incur the minimal overhead of one additional tag per repeating group (NoXXX field), I believe this small change would provide greater clarity and flexibility for encoding and parsing repeating groups.
Joey Horowitz
Aegis Software Inc.
P.S. Adding a new (optional) BeginRepeatingGroup tag would also be nice, and allow for the creation of custom repeating groups (this should be considered separately).
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
Joey,
This good suggestion generated quite a lot of discussion in the Tech Committee, and we think it has merrit. However the freedom that it would bring to the format also implies change to repeating-group parsing logic, suggesting that we carry it over to a major release of the spec (e.g. 5.0) rather than 4.4. In the meantime we hope to draft a "white paper" on FIX engine features that addresses sticky issues like the ones you describe here.
Dean Kauffman, co-chair FIX Global Technical Committee
> Originally posted by Benedict Zoe of Bloomberg ( http://www.fixprotocol.org/cgi-bin/BBS.cgi?menu=712&board=3&message=26&thread=26 ), I think this idea is worth repeating (small pun intended).
>
> May I suggest adding a new EndRepeatingGroup tag, to indicate the end of a repeating group. Utilizing such a tag would provide several advantages:
>
> 1. Eliminate the restriction: "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." - since it would now be clear where the repeating group ends and the base message, or outer repeating group, continues.
>
> 2. Eliminate the ambiguity, or error, that can occur in the rare case when the same tag is defined within the middle of a repeating group and within the base message, or outer repeating group.
>
> 3. Make the use of Custom Tags within a repeating group unambiguous and permissible. As the specification stands today, there is no clear definition where a Custom Tag may be placed within a repeating group. The problem becomes more difficult when parsing the last repeated instance.
>
> Although this change would incur the minimal overhead of one additional tag per repeating group (NoXXX field), I believe this small change would provide greater clarity and flexibility for encoding and parsing repeating groups.
>
> Joey Horowitz
> Aegis Software Inc.
>
> P.S. Adding a new (optional) BeginRepeatingGroup tag would also be nice, and allow for the creation of custom repeating groups (this should be considered separately).
>
>
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
> Joey,
>
> This good suggestion generated quite a lot of discussion in the Tech Committee, and we think it has merrit. However the freedom that it would bring to the format also implies change to repeating-group parsing logic, suggesting that we carry it over to a major release of the spec (e.g. 5.0) rather than 4.4. In the meantime we hope to draft a "white paper" on FIX engine features that addresses sticky issues like the ones you describe here.
> Dean Kauffman, co-chair FIX Global Technical Committee
>
> > Originally posted by Benedict Zoe of Bloomberg ( http://www.fixprotocol.org/cgi-bin/BBS.cgi?menu=712&board=3&message=26&thread=26 ), I think this idea is worth repeating (small pun intended).
> >
> > May I suggest adding a new EndRepeatingGroup tag, to indicate the end of a repeating group. Utilizing such a tag would provide several advantages:
> >
> > 1. Eliminate the restriction: "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." - since it would now be clear where the repeating group ends and the base message, or outer repeating group, continues.
> >
> > 2. Eliminate the ambiguity, or error, that can occur in the rare case when the same tag is defined within the middle of a repeating group and within the base message, or outer repeating group.
> >
> > 3. Make the use of Custom Tags within a repeating group unambiguous and permissible. As the specification stands today, there is no clear definition where a Custom Tag may be placed within a repeating group. The problem becomes more difficult when parsing the last repeated instance.
> >
> > Although this change would incur the minimal overhead of one additional tag per repeating group (NoXXX field), I believe this small change would provide greater clarity and flexibility for encoding and parsing repeating groups.
> >
> > Joey Horowitz
> > Aegis Software Inc.
> >
> > P.S. Adding a new (optional) BeginRepeatingGroup tag would also be nice, and allow for the creation of custom repeating groups (this should be considered separately).
> >
> >
>
Joey, Dean,
I would like to submit an alternative solution to the problems related to the repeating groups invoked by Joey.
The fields belonging to nested groups may be indented by extra SOH characters making the originally flat messages a hierarchical structure. Given we know the nesting depth, the number of preceding separators must be exactly the same.
No extra tags are required. It seems to be extremely easy to implement and to add in existing FIX engines. It offers hight performance parsing. It is simply natural.
Example:
FIX4.? actual
…[SOH]
FieldXYZ=valueXYZ[SOH]
NoGroupA=2[SOH]
DelimA=Y[SOH]
FiledA1=J[SOH]
FieldA2=K[SOH]
DelimA=N[SOH]
NoGroupAB=1[SOH]
DelimAB=foo[SOH]
FieldZYX=ValueZYX[SOH]
…
FIX? indented
…[SOH]
FieldXYZ=ValueXYZ[SOH]
NoGroupA=2[SOH]
[SOH]DelimA=Y[SOH]
[SOH]FiledA1=J[SOH]
[SOH]FieldA2=K[SOH]
[SOH]DelimA=N[SOH]
[SOH]NoGroupAB=1[SOH]
[SOH][SOH]DelimAB=foo[SOH]
FieldZYX=ValueZYX[SOH]
…
Alex
> Joey,
>
> This good suggestion generated quite a lot of discussion in the Tech Committee, and we think it has merrit. However the freedom that it would bring to the format also implies change to repeating-group parsing logic, suggesting that we carry it over to a major release of the spec (e.g. 5.0) rather than 4.4. In the meantime we hope to draft a "white paper" on FIX engine features that addresses sticky issues like the ones you describe here.
> Dean Kauffman, co-chair FIX Global Technical Committee
>
> > Originally posted by Benedict Zoe of Bloomberg ( http://www.fixprotocol.org/cgi-bin/BBS.cgi?menu=712&board=3&message=26&thread=26 ), I think this idea is worth repeating (small pun intended).
> >
> > May I suggest adding a new EndRepeatingGroup tag, to indicate the end of a repeating group. Utilizing such a tag would provide several advantages:
> >
> > 1. Eliminate the restriction: "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." - since it would now be clear where the repeating group ends and the base message, or outer repeating group, continues.
> >
> > 2. Eliminate the ambiguity, or error, that can occur in the rare case when the same tag is defined within the middle of a repeating group and within the base message, or outer repeating group.
> >
> > 3. Make the use of Custom Tags within a repeating group unambiguous and permissible. As the specification stands today, there is no clear definition where a Custom Tag may be placed within a repeating group. The problem becomes more difficult when parsing the last repeated instance.
> >
> > Although this change would incur the minimal overhead of one additional tag per repeating group (NoXXX field), I believe this small change would provide greater clarity and flexibility for encoding and parsing repeating groups.
> >
> > Joey Horowitz
> > Aegis Software Inc.
> >
> > P.S. Adding a new (optional) BeginRepeatingGroup tag would also be nice, and allow for the creation of custom repeating groups (this should be considered separately).
> >
> >
>
[ original email was from Joseph Horowitz - jhorowitz@aegisoft.com ]
Hi Alex,
I hope the FPL committee considers your alternate suggestion for the next version of FIX.
I would counter that if you send a large message, such as a New Order List (MsgType=E), with many orders embedded your solution would create a much larger message. Whereas my suggestion would add 1 tag (e.g. 999=0[SOH]) for a total of 6 additional characters.
It’s hard to claim that one solution or another would be easier or harder for any particular vendor to support. However I do think that keeping to the tag=value paradigm would be helpful to any engine already built to parse such syntax.
Thanks!
-Joey