Imported from previous forum
Hi could someone please clarify a case in point for me.
While I know that in a FIX 4.4 message the NoXXX field must immediately precede the delimiter field of a repeating group, how does that stand in a FIX 4.1 message.
For instance would a FIX 4.1 message still be a valid if the repeating group was specified in the following way:
NoXXX tags
Non-repeating group tag
Non-repeating group tag
->Repeating group delimiter
->Repeating group tag
Non-repeating group tag
We are connecting to a system that uses FIX 4.1 only and as there is nothing in the FIX 4.1 spec saying that the NoXxX tag must immediately precede the repeating group, our counterparty is insisting that it is valid.
In the IOI spec under FIXimate under FIX 4.1 however the NoXXX tag is considered part of the repeating group block and I had always viewed the NoXXX as essentially part of that block.
Could someone elaborate or is this open to interpretation?
Phillip - my previous firm did a lot of work with the EMX funds network in the UK (part of Euroclear, I believe) - EMX uses v4.1 of the protocol (with a lot of custom messages/tags) and they require the repeating block count field to immediately follow rather than precede the repeating block. I think it was a historical artifact based on lack of experience with the protocol when their spec was defined, and at the time we argued it wasn’t standard FIX, but they correctly countered that the spec didn’t forbid it, so we had to comply and put special code in our engine to support it.
However, your example shows the repeating block count completely separate from the repeating block; I would argue that this is a very bad idea on the part of the implementer as it makes parsing/validating repeating blocks all the more awkward.
HTH.
Hi Steve
This is actually EMX we are dealing with and with have had the same discussion with them recently. However we fell to the same arguement.
This is actually a valid message that passed their hub and they have stated it is possible to receive this message from their web message platform.
We had code to handle them being at the end of the block or beginning but this is something entirely new.
Interesting to see what people do in the name of FIX. Lack of clarity or ambiguity in older versions of the protocol should not be used as an argument. You cannot expect FPL to define what it is not, i.e. to list everything that is forbidden. One needs to understand the concepts of FIX and adhere to them even if one does not find an exact description. Sometimes, higher versions have clarified concept details so it is worth looking into the most recent spec even if one does not support that version.
Looking at he specific case of repeating groups, it is a clear example of a clarification being provided with the next version (FIX 4.2):
“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. The NoXXX field where XXX is the field being counted specifies the number of repeating group instances that must immediately precede the repeating group contents.”
The fact that FIX 4.1 did not have this verbiage does not mean that there was a change between versions. FIX 4.2 was released in March 2000, i.e. more than ten years ago. As it is in the interest of the FIX community, it is hard to believe why it is not possible to change the encoding of repeating groups to be FIX 4.2 compliant which would also be FIX 5.0 SP2 compliant. NoXXX and the first field of a group still serve as delimiters to ease parsing of repeating groups in the tag=value syntax. I hope that these kind of examples are far and few amongst all old implementations of FIX that are out there and still able to make money for those who once built them. Ease of access is a key benefit of FIX and this example does not help to prove that point.
Regards,
Hanno.
Phillip - my previous firm did a lot of work with the EMX funds network in the UK (part of Euroclear, I believe) - EMX uses v4.1 of the protocol (with a lot of custom messages/tags) and they require the repeating block count field to immediately follow rather than precede the repeating block. I think it was a historical artifact based on lack of experience with the protocol when their spec was defined, and at the time we argued it wasn’t standard FIX, but they correctly countered that the spec didn’t forbid it, so we had to comply and put special code in our engine to support it.
However, your example shows the repeating block count completely separate from the repeating block; I would argue that this is a very bad idea on the part of the implementer as it makes parsing/validating repeating blocks all the more awkward.
HTH.
Hi Steve
This is actually EMX we are dealing with and with have had the same discussion with them recently. However we fell to the same arguement.
This is actually a valid message that passed their hub and they have stated it is possible to receive this message from their web message platform.We had code to handle them being at the end of the block or beginning but this is something entirely new.
Just to confirm if the NoXXX field is zero - say for example in a reject message then no repeating group instances should be expected by the counterparty.
-Aditya
Interesting to see what people do in the name of FIX. Lack of clarity or ambiguity in older versions of the protocol should not be used as an argument. You cannot expect FPL to define what it is not, i.e. to list everything that is forbidden. One needs to understand the concepts of FIX and adhere to them even if one does not find an exact description. Sometimes, higher versions have clarified concept details so it is worth looking into the most recent spec even if one does not support that version.
Looking at he specific case of repeating groups, it is a clear example of a clarification being provided with the next version (FIX 4.2):
“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. The NoXXX field where XXX is the field being counted specifies the number of repeating group instances that must immediately precede the repeating group contents.”
The fact that FIX 4.1 did not have this verbiage does not mean that there was a change between versions. FIX 4.2 was released in March 2000, i.e. more than ten years ago. As it is in the interest of the FIX community, it is hard to believe why it is not possible to change the encoding of repeating groups to be FIX 4.2 compliant which would also be FIX 5.0 SP2 compliant. NoXXX and the first field of a group still serve as delimiters to ease parsing of repeating groups in the tag=value syntax. I hope that these kind of examples are far and few amongst all old implementations of FIX that are out there and still able to make money for those who once built them. Ease of access is a key benefit of FIX and this example does not help to prove that point.
Regards,
Hanno.Phillip - my previous firm did a lot of work with the EMX funds network in the UK (part of Euroclear, I believe) - EMX uses v4.1 of the protocol (with a lot of custom messages/tags) and they require the repeating block count field to immediately follow rather than precede the repeating block. I think it was a historical artifact based on lack of experience with the protocol when their spec was defined, and at the time we argued it wasn’t standard FIX, but they correctly countered that the spec didn’t forbid it, so we had to comply and put special code in our engine to support it.
However, your example shows the repeating block count completely separate from the repeating block; I would argue that this is a very bad idea on the part of the implementer as it makes parsing/validating repeating blocks all the more awkward.
HTH.
Hi Steve
This is actually EMX we are dealing with and with have had the same discussion with them recently. However we fell to the same arguement.
This is actually a valid message that passed their hub and they have stated it is possible to receive this message from their web message platform.We had code to handle them being at the end of the block or beginning but this is something entirely new.
As a recipient of messages you should be defensive, i.e. be prepared for NoXXX=0. From a FIX compliance point, NoXXX should not be sent but is technically permitted if the repeating group is optional. The ambiguity was clarified in FIX 5.0 SP2 Volume 1 as follows:
- Sending NoXXX=0 (e.g. NoPartyIDs=0) for optional repeating group is valid but not recommended.
- Recipients should be able to accept NoXXX=0, but Recipients should not require this.
- Senders should never send NoXXX=0.
- For repeating groups that are marked as required, sending NoXXX=0 is not FIX compliant.
Regards,
Hanno.
Just to confirm if the NoXXX field is zero - say for example in a reject message then no repeating group instances should be expected by the counterparty.
-Aditya
Interesting to see what people do in the name of FIX. Lack of clarity or ambiguity in older versions of the protocol should not be used as an argument. You cannot expect FPL to define what it is not, i.e. to list everything that is forbidden. One needs to understand the concepts of FIX and adhere to them even if one does not find an exact description. Sometimes, higher versions have clarified concept details so it is worth looking into the most recent spec even if one does not support that version.
Looking at he specific case of repeating groups, it is a clear example of a clarification being provided with the next version (FIX 4.2):
“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. The NoXXX field where XXX is the field being counted specifies the number of repeating group instances that must immediately precede the repeating group contents.”
The fact that FIX 4.1 did not have this verbiage does not mean that there was a change between versions. FIX 4.2 was released in March 2000, i.e. more than ten years ago. As it is in the interest of the FIX community, it is hard to believe why it is not possible to change the encoding of repeating groups to be FIX 4.2 compliant which would also be FIX 5.0 SP2 compliant. NoXXX and the first field of a group still serve as delimiters to ease parsing of repeating groups in the tag=value syntax. I hope that these kind of examples are far and few amongst all old implementations of FIX that are out there and still able to make money for those who once built them. Ease of access is a key benefit of FIX and this example does not help to prove that point.
Regards,
Hanno.Phillip - my previous firm did a lot of work with the EMX funds network in the UK (part of Euroclear, I believe) - EMX uses v4.1 of the protocol (with a lot of custom messages/tags) and they require the repeating block count field to immediately follow rather than precede the repeating block. I think it was a historical artifact based on lack of experience with the protocol when their spec was defined, and at the time we argued it wasn’t standard FIX, but they correctly countered that the spec didn’t forbid it, so we had to comply and put special code in our engine to support it.
However, your example shows the repeating block count completely separate from the repeating block; I would argue that this is a very bad idea on the part of the implementer as it makes parsing/validating repeating blocks all the more awkward.
HTH.
Hi Steve
This is actually EMX we are dealing with and with have had the same discussion with them recently. However we fell to the same arguement.
This is actually a valid message that passed their hub and they have stated it is possible to receive this message from their web message platform.We had code to handle them being at the end of the block or beginning but this is something entirely new.
I have posted this clarification on to FIXwiki in the page describing the NumInGroup data type - see Welcome fixwiki.org - BlueHost.com
As a recipient of messages you should be defensive, i.e. be prepared for NoXXX=0. From a FIX compliance point, NoXXX should not be sent but is technically permitted if the repeating group is optional. The ambiguity was clarified in FIX 5.0 SP2 Volume 1 as follows:
- Sending NoXXX=0 (e.g. NoPartyIDs=0) for optional repeating group is valid but not recommended.
- Recipients should be able to accept NoXXX=0, but Recipients should not require this.
- Senders should never send NoXXX=0.
- For repeating groups that are marked as required, sending NoXXX=0 is not FIX compliant.
Regards,
Hanno.Just to confirm if the NoXXX field is zero - say for example in a reject message then no repeating group instances should be expected by the counterparty.
-Aditya
Interesting to see what people do in the name of FIX. Lack of clarity or ambiguity in older versions of the protocol should not be used as an argument. You cannot expect FPL to define what it is not, i.e. to list everything that is forbidden. One needs to understand the concepts of FIX and adhere to them even if one does not find an exact description. Sometimes, higher versions have clarified concept details so it is worth looking into the most recent spec even if one does not support that version.
Looking at he specific case of repeating groups, it is a clear example of a clarification being provided with the next version (FIX 4.2):
“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. The NoXXX field where XXX is the field being counted specifies the number of repeating group instances that must immediately precede the repeating group contents.”
The fact that FIX 4.1 did not have this verbiage does not mean that there was a change between versions. FIX 4.2 was released in March 2000, i.e. more than ten years ago. As it is in the interest of the FIX community, it is hard to believe why it is not possible to change the encoding of repeating groups to be FIX 4.2 compliant which would also be FIX 5.0 SP2 compliant. NoXXX and the first field of a group still serve as delimiters to ease parsing of repeating groups in the tag=value syntax. I hope that these kind of examples are far and few amongst all old implementations of FIX that are out there and still able to make money for those who once built them. Ease of access is a key benefit of FIX and this example does not help to prove that point.
Regards,
Hanno.Phillip - my previous firm did a lot of work with the EMX funds network in the UK (part of Euroclear, I believe) - EMX uses v4.1 of the protocol (with a lot of custom messages/tags) and they require the repeating block count field to immediately follow rather than precede the repeating block. I think it was a historical artifact based on lack of experience with the protocol when their spec was defined, and at the time we argued it wasn’t standard FIX, but they correctly countered that the spec didn’t forbid it, so we had to comply and put special code in our engine to support it.
However, your example shows the repeating block count completely separate from the repeating block; I would argue that this is a very bad idea on the part of the implementer as it makes parsing/validating repeating blocks all the more awkward.
HTH.
Hi Steve
This is actually EMX we are dealing with and with have had the same discussion with them recently. However we fell to the same arguement.
This is actually a valid message that passed their hub and they have stated it is possible to receive this message from their web message platform.We had code to handle them being at the end of the block or beginning but this is something entirely new.
Got it thanks - basically it sounds like this is bad practice so it may be better to stay away from sending NoXXX as 0 regardless of whether the repeating group is required or optional.
-Aditya Kapur
As a recipient of messages you should be defensive, i.e. be prepared for NoXXX=0. From a FIX compliance point, NoXXX should not be sent but is technically permitted if the repeating group is optional. The ambiguity was clarified in FIX 5.0 SP2 Volume 1 as follows:
- Sending NoXXX=0 (e.g. NoPartyIDs=0) for optional repeating group is valid but not recommended.
- Recipients should be able to accept NoXXX=0, but Recipients should not require this.
- Senders should never send NoXXX=0.
- For repeating groups that are marked as required, sending NoXXX=0 is not FIX compliant.
Regards,
Hanno.Just to confirm if the NoXXX field is zero - say for example in a reject message then no repeating group instances should be expected by the counterparty.
-Aditya
Interesting to see what people do in the name of FIX. Lack of clarity or ambiguity in older versions of the protocol should not be used as an argument. You cannot expect FPL to define what it is not, i.e. to list everything that is forbidden. One needs to understand the concepts of FIX and adhere to them even if one does not find an exact description. Sometimes, higher versions have clarified concept details so it is worth looking into the most recent spec even if one does not support that version.
Looking at he specific case of repeating groups, it is a clear example of a clarification being provided with the next version (FIX 4.2):
“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. The NoXXX field where XXX is the field being counted specifies the number of repeating group instances that must immediately precede the repeating group contents.”
The fact that FIX 4.1 did not have this verbiage does not mean that there was a change between versions. FIX 4.2 was released in March 2000, i.e. more than ten years ago. As it is in the interest of the FIX community, it is hard to believe why it is not possible to change the encoding of repeating groups to be FIX 4.2 compliant which would also be FIX 5.0 SP2 compliant. NoXXX and the first field of a group still serve as delimiters to ease parsing of repeating groups in the tag=value syntax. I hope that these kind of examples are far and few amongst all old implementations of FIX that are out there and still able to make money for those who once built them. Ease of access is a key benefit of FIX and this example does not help to prove that point.
Regards,
Hanno.Phillip - my previous firm did a lot of work with the EMX funds network in the UK (part of Euroclear, I believe) - EMX uses v4.1 of the protocol (with a lot of custom messages/tags) and they require the repeating block count field to immediately follow rather than precede the repeating block. I think it was a historical artifact based on lack of experience with the protocol when their spec was defined, and at the time we argued it wasn’t standard FIX, but they correctly countered that the spec didn’t forbid it, so we had to comply and put special code in our engine to support it.
However, your example shows the repeating block count completely separate from the repeating block; I would argue that this is a very bad idea on the part of the implementer as it makes parsing/validating repeating blocks all the more awkward.
HTH.
Hi Steve
This is actually EMX we are dealing with and with have had the same discussion with them recently. However we fell to the same arguement.
This is actually a valid message that passed their hub and they have stated it is possible to receive this message from their web message platform.We had code to handle them being at the end of the block or beginning but this is something entirely new.
Hi,
just a question out of curiosity: is it FIX-conform to have a repeating group nested as a first element of an outer repeating group? E.g.:
…
…
Given the rule that the first field of a repeating group is always required that would mean the NoQuoteEntries field was required?
I did not find any contradiction in the FIX5.0 spec but that case was not explicitly listed either.
Thanks in advance and best regards,
Christoph John
As a recipient of messages you should be defensive, i.e. be prepared for NoXXX=0. From a FIX compliance point, NoXXX should not be sent but is technically permitted if the repeating group is optional. The ambiguity was clarified in FIX 5.0 SP2 Volume 1 as follows:
- Sending NoXXX=0 (e.g. NoPartyIDs=0) for optional repeating group is valid but not recommended.
- Recipients should be able to accept NoXXX=0, but Recipients should not require this.
- Senders should never send NoXXX=0.
- For repeating groups that are marked as required, sending NoXXX=0 is not FIX compliant.
Regards,
Hanno.
Christoph,
Yes, it is possible to have a repeating group where the first immediate field is another repeating group. This is FIX compliant and have been used by components such as the PartyRiskLimitsGrp component. However, in designing a component such as this, one need to be careful to ensure that the rule of the first field in the repeating group being required will still be valid regardless of the many scenarios.
Hope this helps.
Hi,
just a question out of curiosity: is it FIX-conform to have a repeating group nested as a first element of an outer repeating group? E.g.:
…
…Given the rule that the first field of a repeating group is always required that would mean the NoQuoteEntries field was required?
I did not find any contradiction in the FIX5.0 spec but that case was not explicitly listed either.
Thanks in advance and best regards,
Christoph JohnAs a recipient of messages you should be defensive, i.e. be prepared for NoXXX=0. From a FIX compliance point, NoXXX should not be sent but is technically permitted if the repeating group is optional. The ambiguity was clarified in FIX 5.0 SP2 Volume 1 as follows:
- Sending NoXXX=0 (e.g. NoPartyIDs=0) for optional repeating group is valid but not recommended.
- Recipients should be able to accept NoXXX=0, but Recipients should not require this.
- Senders should never send NoXXX=0.
- For repeating groups that are marked as required, sending NoXXX=0 is not FIX compliant.
Regards,
Hanno.