# Some concerns: FIXML over FIX and FIXXT1.1 multiple version support **URL:** \ **Category:** General Q&A\ **Tags:** imported, implementation--opti, xid\_164191\ **Created:** [December 15, 2008, 3:22am UTC](https://forum.fixtrading.org/t/some-concerns-fixml-over-fix-and-fixxt1-1-multiple-version-support/12362 "2008-12-15T03:22:30Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![qingjunwei76\_x](https://avatars.discourse-cdn.com/v4/letter/q/848f3c/32.png) [@qingjunwei76\_x](https://forum.fixtrading.org/u/qingjunwei76_x)\ **Post date:** [December 15, 2008, 3:22am UTC](https://forum.fixtrading.org/t/some-concerns-fixml-over-fix-and-fixxt1-1-multiple-version-support/12362/1 "2008-12-15T03:22:30Z")
Imported from previous forum ---
**Author:** ![qingjunwei76\_x](https://avatars.discourse-cdn.com/v4/letter/q/848f3c/32.png) [@qingjunwei76\_x](https://forum.fixtrading.org/u/qingjunwei76_x)\ **Post date:** [December 15, 2008, 3:22am UTC](https://forum.fixtrading.org/t/some-concerns-fixml-over-fix-and-fixxt1-1-multiple-version-support/12362/2 "2008-12-15T03:22:30Z")
We have concerns over some of the design perspective of the FIX protocol. 1. 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. 2. 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. ---
**Author:** ![scott.atwell](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@scott.atwell](https://forum.fixtrading.org/u/scott.atwell)\ **Post date:** [December 15, 2008, 3:40am UTC](https://forum.fixtrading.org/t/some-concerns-fixml-over-fix-and-fixxt1-1-multiple-version-support/12362/3 "2008-12-15T03:40:41Z")
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. > > 1. 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. > > 2. 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. ---
**Author:** ![qingjunwei76\_x](https://avatars.discourse-cdn.com/v4/letter/q/848f3c/32.png) [@qingjunwei76\_x](https://forum.fixtrading.org/u/qingjunwei76_x)\ **Post date:** [December 15, 2008, 6:14am UTC](https://forum.fixtrading.org/t/some-concerns-fixml-over-fix-and-fixxt1-1-multiple-version-support/12362/4 "2008-12-15T06:14:31Z")
> 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. > > > > 1. 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. > > > > 2. 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. ---
**Author:** ![hanno.klein](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/hanno.klein/32/38_2.png) [@hanno.klein](https://forum.fixtrading.org/u/hanno.klein)\ **Post date:** [December 19, 2008, 4:05pm UTC](https://forum.fixtrading.org/t/some-concerns-fixml-over-fix-and-fixxt1-1-multiple-version-support/12362/5 "2008-12-19T16:05:25Z")
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. ---
**Author:** ![qingjunwei76\_x](https://avatars.discourse-cdn.com/v4/letter/q/848f3c/32.png) [@qingjunwei76\_x](https://forum.fixtrading.org/u/qingjunwei76_x)\ **Post date:** [December 20, 2008, 12:42am UTC](https://forum.fixtrading.org/t/some-concerns-fixml-over-fix-and-fixxt1-1-multiple-version-support/12362/6 "2008-12-20T00:42:09Z")
> 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. ---
**Author:** ![rolfandersson58\_x](https://avatars.discourse-cdn.com/v4/letter/r/b9e5f3/32.png) [@rolfandersson58\_x](https://forum.fixtrading.org/u/rolfandersson58_x)\ **Post date:** [December 20, 2008, 12:48am UTC](https://forum.fixtrading.org/t/some-concerns-fixml-over-fix-and-fixxt1-1-multiple-version-support/12362/7 "2008-12-20T00:48:20Z")
> 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. ---
**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\ **Post date:** [December 20, 2008, 9:41am UTC](https://forum.fixtrading.org/t/some-concerns-fixml-over-fix-and-fixxt1-1-multiple-version-support/12362/8 "2008-12-20T09:41:34Z")
[original email was from Kevin Houstoun - [kevinh@altkb.com](mailto: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. 1. 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. > > 1. 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. > > 2. 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.