Imported from previous forum
Hi All,
Right now, it seems that the application messages in the FIX 5.0 repository reference an explicit FIXT.1.1 header/trailer layout when you resolve their “StandardHeader/StandardTrailer” elements:
What happens when there are multiple versions of the FIX session layer in the FIX repository?
Russ,
There is a separate FIXT.1.1 repository as of this release of FIX.
We have contemplated removing the standard header and trailer from FIX.5.0. I am not sure this is a good idea. So the concept here is that FIXT has its own header- and the standard header actually spans the session layer and the application layer (by spanning I mean it should be presented and accessible at the application level). So what is need to maintain compatibility with previous versions of FIX is a mapping table between the FIXT Standard Header and FIX.4.0 through FIX.5.0 Standard Headers. True, this mapping is largely trivial, but it is still an important mapping.
With the FIXT.1.1 Errata that was released coincidentally with FIX.5.0SP1 we added this mapping table as an appendix to the FIXT.1.1 specification. FIX implementors supporting FIX.5.0 and Application Version Independence should reference this table in mapping from FIXT based messages back to their APIs for previous versions of FIX. (You can support FIX.5.0 without supporting application version independence - though as a software vendor - you are probably better positioned if you offer full compatibility with the standard instead of subset).
I hope this helps.
Hi All,
Right now, it seems that the application messages in the FIX 5.0
repository reference an explicit FIXT.1.1 header/trailer layout when you
resolve their “StandardHeader/StandardTrailer” elements:What happens when there are multiple versions of the FIX session layer
in the FIX repository?
Russ,
There is a separate FIXT.1.1 repository as of this release of FIX.
We have contemplated removing the standard header and trailer from
FIX.5.0. I am not sure this is a good idea. So the concept here is that
FIXT has its own header- and the standard header actually spans the
session layer and the application layer (by spanning I mean it should be
presented and accessible at the application level). So what is need to
maintain compatibility with previous versions of FIX is a mapping table
between the FIXT Standard Header and FIX.4.0 through FIX.5.0 Standard
Headers. True, this mapping is largely trivial, but it is still an
important mapping.With the FIXT.1.1 Errata that was released coincidentally with
FIX.5.0SP1 we added this mapping table as an appendix to the FIXT.1.1
specification. FIX implementors supporting FIX.5.0 and Application
Version Independence should reference this table in mapping from FIXT
based messages back to their APIs for previous versions of FIX. (You can
support FIX.5.0 without supporting application version independence -
though as a software vendor - you are probably better positioned if you
offer full compatibility with the standard instead of subset).I hope this helps.
Hi Jim,
Thanks - that makes sense. Our implementation of 5.0 completely separates the session from the application layer, so the explicit references in the repository just made me wonder if there was some other wierdness in store. Is the mapping table going to be integrated into the repository in the future - so validation/correctness data can be generated automatically from each release of the repository rather than having to manually enter it from a document?
Cheers,
Russ
Russ,
It is on my list for repository revisions once we reconstitute the repository working group. I agree it should be captured as metadata to simplify the work required by vendors and to increase the likelyhood of sstandardized implementations.
Russ,
There is a separate FIXT.1.1 repository as of this release of FIX.
We have contemplated removing the standard header and trailer from
FIX.5.0. I am not sure this is a good idea. So the concept here is
that FIXT has its own header- and the standard header actually spans
the session layer and the application layer (by spanning I mean it
should be presented and accessible at the application level). So what
is need to maintain compatibility with previous versions of FIX is a
mapping table between the FIXT Standard Header and FIX.4.0 through
FIX.5.0 Standard Headers. True, this mapping is largely trivial, but
it is still an important mapping.With the FIXT.1.1 Errata that was released coincidentally with
FIX.5.0SP1 we added this mapping table as an appendix to the FIXT.1.1
specification. FIX implementors supporting FIX.5.0 and Application
Version Independence should reference this table in mapping from FIXT
based messages back to their APIs for previous versions of FIX. (You
can support FIX.5.0 without supporting application version
independence - though as a software vendor - you are probably better
positioned if you offer full compatibility with the standard instead
of subset).I hope this helps.
Hi Jim,
Thanks - that makes sense. Our implementation of 5.0 completely
separates the session from the application layer, so the explicit
references in the repository just made me wonder if there was some other
wierdness in store. Is the mapping table going to be integrated into the
repository in the future - so validation/correctness data can be
generated automatically from each release of the repository rather than
having to manually enter it from a document?Cheers,
Russ