Imported from previous forum
Hi All, In the FIX specification for FIX 5.0, it seems to indicate that both the base FIX version and the applicable service pack are indicated by the ApplVerID field - is this correct? If that's the case, the enumerations in the repository only go to '7' within the FIX 5.0 SP2 repository; shouldn't they go to 9 right now? 7 - FIX 5.0 8 - FIX 5.0 + SP1 9 - FIX 5.0 + SP2 Or am I misreading the specification on this? Thanks, Russ
Hi All,
In the FIX specification for FIX 5.0, it seems to indicate that both the
base FIX version and the applicable service pack are indicated by the
ApplVerID field - is this correct?If that’s the case, the enumerations in the repository only go to ‘7’
within the FIX 5.0 SP2 repository; shouldn’t they go to 9 right now?7 - FIX 5.0 8 - FIX 5.0 + SP1 9 - FIX 5.0 + SP2
Or am I misreading the specification on this?
Thanks,
Russ
Ah, never mind - this is actually the role of tag 1156, right?
Hi All,
In the FIX specification for FIX 5.0, it seems to indicate that both
the base FIX version and the applicable service pack are indicated by
the ApplVerID field - is this correct?If that’s the case, the enumerations in the repository only go to ‘7’
within the FIX 5.0 SP2 repository; shouldn’t they go to 9 right now?7 - FIX 5.0 8 - FIX 5.0 + SP1 9 - FIX 5.0 + SP2
Or am I misreading the specification on this?
Thanks,
Russ
Ah, never mind - this is actually the role of tag 1156, right?
This leads to a related question:
The specification then says that tag 1156 will contain the service pack identifier and that identifier is a long text string ala:
“FIX 5.0 SP1 June 30 2007”
Is this identifier actually stored in the repository somewhere, so that tools don’t have to worry about the user correctly defining the service pack name when generating a dictionary, etc.?
Shouldn’t this really just be an enumeration as well, or shouldn’t the enumerations just take service packs into account? Considering how many years FIX has been in service, and there are currently only seven values need in the ApplVerID enum to represent all known versions of FIX, why not just make this easier to parse and deal with by consolidating everything into the ApplVerID enumeration? This just seems like an awful lot of overhead just to figure out what version of a FIX message a system is looking at…
1156 (ApplExtID) is meant to be used only for an extension pack number and it is an integer.
If you wanted to specify EP102 for FIX.5.0SP2 you would set:
1128=9^1156=102
As you point out in your original email - 8=FIX.5.0SP1 is listed as an enumeration for ApplVerID, but there is no “9” why?
Because the field 1128(ApplVerID) is in the FIXT.1.1 Session Layer - which is versioned completely separately than the FIX Application Version. I made a point of not adding it when we released FIX.5.0SP2 to point out that we did not achieve Application Version Independence like we thought. So now that point is proved I suspect we should issue another Errata to FIXT.1.1 to include the enumeration for FIX.5.0SP2. Or maybe it is best we just put a note in the FIXT specification that each time we add a new Service Pack the ApplVerID enumerations will be changed. Awkward.
We will obviously discuss this in the Repository Working Group some more.
Hope this helps.
Hi All,
In the FIX specification for FIX 5.0, it seems to indicate that both
the base FIX version and the applicable service pack are indicated
by the ApplVerID field - is this correct?If that’s the case, the enumerations in the repository only go to
‘7’ within the FIX 5.0 SP2 repository; shouldn’t they go to 9
right now?7 - FIX 5.0 8 - FIX 5.0 + SP1 9 - FIX 5.0 + SP2
Or am I misreading the specification on this?
Thanks,
Russ
Ah, never mind - this is actually the role of tag 1156, right?
This leads to a related question:
The specification then says that tag 1156 will contain the service pack
identifier and that identifier is a long text string ala:“FIX 5.0 SP1 June 30 2007”
Is this identifier actually stored in the repository somewhere, so that
tools don’t have to worry about the user correctly defining the service
pack name when generating a dictionary, etc.?Shouldn’t this really just be an enumeration as well, or shouldn’t the
enumerations just take service packs into account? Considering how many
years FIX has been in service, and there are currently only seven values
need in the ApplVerID enum to represent all known versions of FIX, why
not just make this easier to parse and deal with by consolidating
everything into the ApplVerID enumeration? This just seems like an awful
lot of overhead just to figure out what version of a FIX message a
system is looking at…
Hi Jim,
Ah, now I get it - I was running through pages 12 and 13 in the FIX 5.0 SP2 spec and transposed “service pack identifier” with “extension pack identifier.” while reading pages 12 through 13, thus causing myself some confusion… 
1156 (ApplExtID) is meant to be used only for an extension pack number
and it is an integer.If you wanted to specify EP102 for FIX.5.0SP2 you would set:
1128=9^1156=102
As you point out in your original email - 8=FIX.5.0SP1 is listed as an
enumeration for ApplVerID, but there is no “9” why?Because the field 1128(ApplVerID) is in the FIXT.1.1 Session Layer -
which is versioned completely separately than the FIX Application
Version. I made a point of not adding it when we released FIX.5.0SP2 to
point out that we did not achieve Application Version Independence like
we thought. So now that point is proved I suspect we should issue
another Errata to FIXT.1.1 to include the enumeration for FIX.5.0SP2. Or
maybe it is best we just put a note in the FIXT specification that each
time we add a new Service Pack the ApplVerID enumerations will be
changed. Awkward.We will obviously discuss this in the Repository Working Group
some more.Hope this helps.
Hi All,
In the FIX specification for FIX 5.0, it seems to indicate that
both the base FIX version and the applicable service pack are
indicated by the ApplVerID field - is this correct?If that’s the case, the enumerations in the repository only go to
‘7’ within the FIX 5.0 SP2 repository; shouldn’t they go to 9
right now?7 - FIX 5.0 8 - FIX 5.0 + SP1 9 - FIX 5.0 + SP2
Or am I misreading the specification on this?
Thanks,
Russ
Ah, never mind - this is actually the role of tag 1156, right?
This leads to a related question:
The specification then says that tag 1156 will contain the service
pack identifier and that identifier is a long text string ala:“FIX 5.0 SP1 June 30 2007”
Is this identifier actually stored in the repository somewhere, so
that tools don’t have to worry about the user correctly defining the
service pack name when generating a dictionary, etc.?Shouldn’t this really just be an enumeration as well, or shouldn’t the
enumerations just take service packs into account? Considering how
many years FIX has been in service, and there are currently only seven
values need in the ApplVerID enum to represent all known versions of
FIX, why not just make this easier to parse and deal with by
consolidating everything into the ApplVerID enumeration? This just
seems like an awful lot of overhead just to figure out what version of
a FIX message a system is looking at…
Jim,
where is “9” actually missing? ApplVerID in FIXimate has it and the repository file Enums.xml also has it. The sorting is maybe not as expected as the first 7 values follow each other and 8 and 9 come later in the file (not even together). Also, the values do not contain any dots, i.e. “FIX50SP1” instead of “FIX.5.0SP1”.
FIXT1.1 does not have its own data dictionary, or does it? It has its own document and versioning but the document only uses the tag number and does not define its enum values.
Can you please check once more and clarify?
Thanks,
Hanno.
1156 (ApplExtID) is meant to be used only for an extension pack number
and it is an integer.If you wanted to specify EP102 for FIX.5.0SP2 you would set:
1128=9^1156=102
As you point out in your original email - 8=FIX.5.0SP1 is listed as an
enumeration for ApplVerID, but there is no “9” why?Because the field 1128(ApplVerID) is in the FIXT.1.1 Session Layer -
which is versioned completely separately than the FIX Application
Version. I made a point of not adding it when we released FIX.5.0SP2 to
point out that we did not achieve Application Version Independence like
we thought. So now that point is proved I suspect we should issue
another Errata to FIXT.1.1 to include the enumeration for FIX.5.0SP2. Or
maybe it is best we just put a note in the FIXT specification that each
time we add a new Service Pack the ApplVerID enumerations will be
changed. Awkward.We will obviously discuss this in the Repository Working Group
some more.Hope this helps.
Hanno,
The FIX.5.0SP2 repository field has been updated as you indicate. But the FIXT.1.1 repository and specification has not been updated and does not contain the value. There is a separate repository for FIXT.1.1, but as reported in a separate discussion item - it was not picked up by the automated build process.
The Repository WG needs to review the decision I made to keep the Standard Header and Standard Trailer with both the FIX5.0xx application layer and the FIXT.1.1 session layer. During the FIXT.1.1 Errata Clive Browning of Rapid Addition and I cleaned up most of the issues that prevented implementation as he was building their implementation.
As of FIXT.1.1 Errata firms can successfully implement FIX.5.0 with FIXT.1.1. The next step is to clarify the conceptual problems that still remaining and fully address the implications of application version independence and the separation of the application layer from the session layer.
Late architecture changes to something conceptually as simple as FIX was and as non-layered as it was - is difficult and often leaves behind a conceptual gordians knot which is usually resolved by making pragmatic choices, such as do we modify FIXT.1.1 each time we release a new service pack. The idealistic answer is “no” as it is a separate layer. The pragmatic answer is “of course” as we need to update the ApplVerID, DefaultApplVerID field enumerations each service pack.
Or we change the definition of the Session Layer ApplVerID to be an integer and leave this value defined by the application layer (whatever that is). This gives us true session layer independence, not unlike what is provided in the Unix System V Transport Layer Independence or Sockets - where the address header is a struct that is treated opaquely by the transport layer.
Best,
Jim N
Jim,
where is “9” actually missing? ApplVerID in FIXimate has it and the
repository file Enums.xml also has it. The sorting is maybe not as
expected as the first 7 values follow each other and 8 and 9 come later
in the file (not even together). Also, the values do not contain any
dots, i.e. “FIX50SP1” instead of “FIX.5.0SP1”.FIXT1.1 does not have its own data dictionary, or does it? It has its
own document and versioning but the document only uses the tag number
and does not define its enum values.Can you please check once more and clarify?
Thanks, Hanno.
1156 (ApplExtID) is meant to be used only for an extension pack number
and it is an integer.If you wanted to specify EP102 for FIX.5.0SP2 you would set:
1128=9^1156=102
As you point out in your original email - 8=FIX.5.0SP1 is listed as an
enumeration for ApplVerID, but there is no “9” why?Because the field 1128(ApplVerID) is in the FIXT.1.1 Session Layer -
which is versioned completely separately than the FIX Application
Version. I made a point of not adding it when we released FIX.5.0SP2
to point out that we did not achieve Application Version Independence
like we thought. So now that point is proved I suspect we should issue
another Errata to FIXT.1.1 to include the enumeration for FIX.5.0SP2.
Or maybe it is best we just put a note in the FIXT specification that
each time we add a new Service Pack the ApplVerID enumerations will be
changed. Awkward.We will obviously discuss this in the Repository Working Group
some more.Hope this helps.