Imported from previous forum
We have concerns over some of the design perspective of the FIX protocol.
-
FIXML over FIX
While we think it’s OK to have an alternative presentation of the FIX message in XML format, it’s arguable why FIXML has to be supported in FIX transport.
FIX transport is designed for FIX specific encoding/decoding and best effort guaranteed delivery of FIX messages (MsgSeqNum and session control etc). Imagine you have a FIX connection already, you already have API for FIX message handling. Why on hell do you have to first encode the message into XML, then embed it into FIX message, and the recipient has to fist decode the FIX message then decode the XML message.
If you are going to use FIXML with other transport, such as message queue products, you don’t have to use FIX transport and the FIX protocol should NOT have the capability of embedding FIXML binary message blocks. -
FIXXT 1.1 and multiple FIX version support
FIXXT 1.1 allows messages with multiple FIX versions transmitted through a single FIX session. the version of the message may be identified by some newly introduced tags such as ApplVerID.
In the specification, there is an example, such as a FIX4.1 new order may have a respond of FIX4.4 execution report from the same session.
Well, logically and theoretically there’s nothing wrong with such design. However, in practice we have to find a use case to justify such design. Who in the right mind would do anything like that? If one has problem handling order management logic within any specific FIX version, how do you expect him/her to handle the logic cross FIX versions? And why would you expect your counter party to handle business logic across different FIX versions like they haven’t got enough trouble?
Let’s propose a new feature in the next release of FIX protocol by adding encoding of TV signals so that we can play TV on our workstation.
re: #2, a use case for version independence in FIXT1.1 is continuing to use existing FIX 4.2 for orderflow and adding use of FIX 4.4-based (or higher) FIX Allocation and Confirmation messages.
We have concerns over some of the design perspective of the FIX
protocol.
FIXML over FIX While we think it’s OK to have an alternative
presentation of the FIX message in XML format, it’s arguable why
FIXML has to be supported in FIX transport. FIX transport is
designed for FIX specific encoding/decoding and best effort
guaranteed delivery of FIX messages (MsgSeqNum and session control
etc). Imagine you have a FIX connection already, you already have
API for FIX message handling. Why on hell do you have to first
encode the message into XML, then embed it into FIX message, and the
recipient has to fist decode the FIX message then decode the XML
message. If you are going to use FIXML with other transport, such as
message queue products, you don’t have to use FIX transport and the
FIX protocol should NOT have the capability of embedding FIXML
binary message blocks.FIXXT 1.1 and multiple FIX version support FIXXT 1.1 allows messages
with multiple FIX versions transmitted through a single FIX session.
the version of the message may be identified by some newly introduced
tags such as ApplVerID.In the specification, there is an example, such as a FIX4.1 new order
may have a respond of FIX4.4 execution report from the same session.
Well, logically and theoretically there’s nothing wrong with such
design. However, in practice we have to find a use case to justify such
design. Who in the right mind would do anything like that? If one has
problem handling order management logic within any specific FIX version,
how do you expect him/her to handle the logic cross FIX versions? And
why would you expect your counter party to handle business logic across
different FIX versions like they haven’t got enough trouble?Let’s propose a new feature in the next release of FIX protocol by
adding encoding of TV signals so that we can play TV on our workstation.
re: #2, a use case for version independence in FIXT1.1 is continuing to
use existing FIX 4.2 for orderflow and adding use of FIX 4.4-based (or
higher) FIX Allocation and Confirmation messages.
First of all, users may have already been unhappy with the constant changes in the order handling related business logic in FIX 4.0, 4.1, 4.2 and 4.3. Of course as vendor we are happy to solve the problem for them.
Secondly, any change has to be bilateral. I fail to see how it is going to make customers’ lives easier. It appears to be easier if both sides decide to keep using FIX 4.2 while adding new message types or custom tags in existing FIX message schema. At least they can just reuse their old FIX engine and don’t have to modify a single line of code for existing application.
Thirdly, the change may create future confusion and I’m sure it will be abused by some really creative fellows.
We have concerns over some of the design perspective of the FIX
protocol.
FIXML over FIX While we think it’s OK to have an alternative
presentation of the FIX message in XML format, it’s arguable why
FIXML has to be supported in FIX transport. FIX transport is
designed for FIX specific encoding/decoding and best effort
guaranteed delivery of FIX messages (MsgSeqNum and session control
etc). Imagine you have a FIX connection already, you already have
API for FIX message handling. Why on hell do you have to first
encode the message into XML, then embed it into FIX message, and
the recipient has to fist decode the FIX message then decode the
XML message. If you are going to use FIXML with other transport,
such as message queue products, you don’t have to use FIX transport
and the FIX protocol should NOT have the capability of embedding
FIXML binary message blocks.FIXXT 1.1 and multiple FIX version support FIXXT 1.1 allows
messages with multiple FIX versions transmitted through a single
FIX session. the version of the message may be identified by some
newly introduced tags such as ApplVerID.In the specification, there is an example, such as a FIX4.1 new order
may have a respond of FIX4.4 execution report from the same session.
Well, logically and theoretically there’s nothing wrong with such
design. However, in practice we have to find a use case to justify
such design. Who in the right mind would do anything like that? If one
has problem handling order management logic within any specific FIX
version, how do you expect him/her to handle the logic cross FIX
versions? And why would you expect your counter party to handle
business logic across different FIX versions like they haven’t got
enough trouble?Let’s propose a new feature in the next release of FIX protocol by
adding encoding of TV signals so that we can play TV on our
workstation.
How do you define “constant change”? FIX 4.0 came out 12 years ago (Jan 1996), FIX 4.1/4.2/4.3 more than 10/8/7 years ago. Any vendor that does not update its software for 7 or more years would be out of business. I also do not know a vendor that adds new features to the software without changing the major or at least the minor version number. Version numbers represent a set of functionality and show progress. I give credit to FPL for being as flexible as they are.
What you are basically asking for is that you stick with an old version for ever and integrate new features into it. I fail to see why you would actually have an old version. Just because you do not change its number in the field BeginString does not mean that you have effort to test the new features you integrate into it. The version number is just the cover.
Maybe your main point is the change of business logic for the plain vanilla order flow that has occurred to some extent over the last 12 years. I would argue that the business logic has been stable since FIX 4.3 which is 7 years ago. You cannot force your customers to go to higher versions but I see no reason why not to advocate it. If you make it all the way to FIX 5.0 you can even continue to use FIX 4.x for order flow and take advantage of new areas of functionality available with higher versions within the same session, e.g. reference data.
Of course there needs to be a business case to move forward. With the old COBOL stuff that was Y2K…what will it be for FIX?
Regards,
Hanno.
First of all, users may have already been unhappy with the constant
changes in the order handling related business logic in FIX 4.0,
4.1, 4.2 and 4.3. Of course as vendor we are happy to solve the
problem for them.Secondly, any change has to be bilateral. I fail to see how it is going
to make customers’ lives easier. It appears to be easier if both sides
decide to keep using FIX 4.2 while adding new message types or custom
tags in existing FIX message schema. At least they can just reuse their
old FIX engine and don’t have to modify a single line of code for
existing application.Thirdly, the change may create future confusion and I’m sure it will be
abused by some really creative fellows.
How do you define “constant change”? FIX 4.0 came out 12 years ago (Jan
1996), FIX 4.1/4.2/4.3 more than 10/8/7 years ago. Any vendor that does
not update its software for 7 or more years would be out of business. I
also do not know a vendor that adds new features to the software without
changing the major or at least the minor version number. Version numbers
represent a set of functionality and show progress. I give credit to FPL
for being as flexible as they are.What you are basically asking for is that you stick with an old version
for ever and integrate new features into it. I fail to see why you
would actually have an old version. Just because you do not change its
number in the field BeginString does not mean that you have effort to
test the new features you integrate into it. The version number is just
the cover.Maybe your main point is the change of business logic for the plain
vanilla order flow that has occurred to some extent over the last 12
years. I would argue that the business logic has been stable since FIX
4.3 which is 7 years ago. You cannot force your customers to go to
higher versions but I see no reason why not to advocate it. If you make
it all the way to FIX 5.0 you can even continue to use FIX 4.x for order
flow and take advantage of new areas of functionality available with
higher versions within the same session, e.g. reference data.Of course there needs to be a business case to move forward. With the
old COBOL stuff that was Y2K…what will it be for FIX?Regards, Hanno.
Yes, I was referring to the order handling business logic. Yes, it has been stable since 4.3. The business logic of 4.0 sucks. 4.2 is not perfect but it’s good enough and I think it’s more widely adopted than 4.3+.
As a vendor I’m happy with constant change. If one is a good player he/she should enjoy a more competitive game. But sometimes enough is enough. Can anybody give me a live example of the real life use case of the multiple version support in FIX 5.0+ and FIXXT 1.1?
First of all, users may have already been unhappy with the constant
changes in the order handling related business logic in FIX 4.0,
4.1, 4.2 and 4.3. Of course as vendor we are happy to solve the
problem for them.Secondly, any change has to be bilateral. I fail to see how it is
going to make customers’ lives easier. It appears to be easier if both
sides decide to keep using FIX 4.2 while adding new message types or
custom tags in existing FIX message schema. At least they can just
reuse their old FIX engine and don’t have to modify a single line of
code for existing application.Thirdly, the change may create future confusion and I’m sure it will
be abused by some really creative fellows.
Can anybody give me a live example of the real life use case of
the multiple version support in FIX 5.0+ and FIXXT 1.1?
I believe Scott did just that in an earlier post.
[ original email was from Kevin Houstoun - kevinh@altkb.com ]
1) There are workflows where it is useful to use an XML product description with a FIX business process. (Tradeweb et al) For these we need the capability to carry XML over FIX; once you have that FIXML is a no brainer. If it is actually used is a different matter but I see little harm in supporting it.
- Realworld examples where TI is useful
i) Expansion into otherpart of the product life cycle
ii) Multiple asset classes
iii) Exchange introducing new features and messages. Many exchanges currently support both thier current and previous order message for example.
Cheers
Kevin
We have concerns over some of the design perspective of the FIX
protocol.
FIXML over FIX While we think it’s OK to have an alternative
presentation of the FIX message in XML format, it’s arguable why
FIXML has to be supported in FIX transport. FIX transport is
designed for FIX specific encoding/decoding and best effort
guaranteed delivery of FIX messages (MsgSeqNum and session control
etc). Imagine you have a FIX connection already, you already have
API for FIX message handling. Why on hell do you have to first
encode the message into XML, then embed it into FIX message, and the
recipient has to fist decode the FIX message then decode the XML
message. If you are going to use FIXML with other transport, such as
message queue products, you don’t have to use FIX transport and the
FIX protocol should NOT have the capability of embedding FIXML
binary message blocks.FIXXT 1.1 and multiple FIX version support FIXXT 1.1 allows messages
with multiple FIX versions transmitted through a single FIX session.
the version of the message may be identified by some newly introduced
tags such as ApplVerID.In the specification, there is an example, such as a FIX4.1 new order
may have a respond of FIX4.4 execution report from the same session.
Well, logically and theoretically there’s nothing wrong with such
design. However, in practice we have to find a use case to justify such
design. Who in the right mind would do anything like that? If one has
problem handling order management logic within any specific FIX version,
how do you expect him/her to handle the logic cross FIX versions? And
why would you expect your counter party to handle business logic across
different FIX versions like they haven’t got enough trouble?Let’s propose a new feature in the next release of FIX protocol by
adding encoding of TV signals so that we can play TV on our workstation.