Imported from previous forum
We have some fields, such as tag 261, 101, and 809 that are undefined in certain versions of FIX. These fields because of naming "(not defined)" and because of datatype "n/a" can cause an issue for users of the repository. I was wondering if there is a better way to represent this in the repository - say by not including fields that don't exist - just omitting the field number. Or does this lead to worse consequences?
We have some fields, such as tag 261, 101, and 809 that are undefined in
certain versions of FIX. These fields because of naming “(not defined)”
and because of datatype “n/a” can cause an issue for users of the
repository. I was wondering if there is a better way to represent this
in the repository - say by not including fields that don’t exist - just
omitting the field number. Or does this lead to worse consequences?
Hi Jim,
The “(not defined)” value might be better as UNDEFINED or RESERVED or something like that, simply from the perspective that the parenthesis might be a nuisance to someone writing a parsing or processing tool…
In terms of the “n/a” for the data type - does that mean the field won’t contain a valid FIX data type, or does that mean the field could contains different data types depending on the context that it is being used in?
The “n/a” means not applicable because the field is not used.
The issue with putting a name of “UNDEFINED” is that it is not unique.
We need to define within the FIX metamodel - whether field names need to be unique in FIX. My opinion is that they have to be unique.
Still wondering if just omitting unused fields would be the sensible thing to do or we could add a datatype of “unused” and then give each field a parsable name “Unused1”, “Unused2”. Still seems a bit hackish.
We have some fields, such as tag 261, 101, and 809 that are undefined
in certain versions of FIX. These fields because of naming “(not
defined)” and because of datatype “n/a” can cause an issue for users
of the repository. I was wondering if there is a better way to
represent this in the repository - say by not including fields that
don’t exist - just omitting the field number. Or does this lead to
worse consequences?Hi Jim,
The “(not defined)” value might be better as UNDEFINED or RESERVED or
something like that, simply from the perspective that the parenthesis
might be a nuisance to someone writing a parsing or processing tool…In terms of the “n/a” for the data type - does that mean the field
won’t contain a valid FIX data type, or does that mean the field could
contains different data types depending on the context that it is
being used in?
[ original email was from John Prewett - jprewett@lavatrading.com ]
Sorry to be late to the party. I’m just implementing a “repository -> my FIX dictionary” converter.
I would definitely prefer the tag to not exist if it doesn’t exist.
Seems really logical to me.
We will try to get approval for this in the next Repository WG meeting.
Sorry to be late to the party. I’m just implementing a “repository → my
FIX dictionary” converter.I would definitely prefer the tag to not exist if it doesn’t exist.
Seems really logical to me.