Imported from previous forum
All,
Question 1:
Is there are any usage statistics for FIX by version.
Really, what I want to know is what version of FIX (4.2, 4.4, 5.0) has the highest number of users / is being used the most for exchange connectivity?
I have a feeling that it is 4.4. I would be inclined to say that there are more 4.2 users than 5.0. But, that is just a guess.
Question 2:
Is there a supported/verified/vetted downloadable file/repository containing the FIX Data Dictionary information in a non-XML format?
I would be ecstatic if someone can point me to a CSV (or similar) file with the following fields:
Tag,FieldName,Required ,DataType,Description/Comments
Int,String ,Char or Bool,String ,String
I’ve looked at FIXwiki’s repository. The last update was in 2009 - too old for my liking.
I don’t want to pull it off some random website I found as the effort to validate the data is just a little less than the mind numbing process of cut-and-paste from the FIX Protocol documentation (word docs) downloadable from this site.
Any and all comments/hints/questions (and yes) criticism greatly appreciated.
Ima
Hi
Maybe someone else can give you the statistics you require but I wonder why you are asking the question. All decent FIX engines will allow you to choose any FIX version you require, just as a configuration change. If you are looking to create a new FIX service, I don’t know of any good arguments why you would not use the most recent FIX version. That is what I have always advised my clients and I am not aware of any that are unhappy with taking that decision.
Regarding your second question - the FIX repository IS the specification. That is the direction in which we are heading. Tools such as FIXimate, FIXwiki and the existing Word and PDF version of the data dictionary are all generated directly from the FIX repository.
(You are correct in noting that the current FIXwiki is a bit out of date but that is because of a minor issue that should be addressed shortly)
As you note, the FIX repository is in the form of XML. XML has its faults, but its big advantage is that it is a widely used standard and there are numerous tools around - many of them free - for processing it.
Here is a little XSLT file which can be used to produce data you require in CSV form:
<?xml version="1.0"?><xsl:stylesheet version=“1.0” xmlns:xsl=“XSLT Namespace”>
<xsl:template match=“Field”>
<xsl:value-of select=“Tag”/>,<xsl:value-of select=“Name”/>,<xsl:value-of select=“Type”/>,<xsl:value-of select=“Description”/>
</xsl:template>
</xsl:stylesheet>
You just apply the above XSLT to the Fields.xml file of the FIX repository.
You could use, for example, the free command line tool “xsltproc” to do this.
Assuming that you have saved the above in a file called test.xslt and that the Fields.xml file is also in the current directory, just type the following:
xsltproc test.xslt Fields.xml
A whole bunch of lines like the following will be output:
1,Account,String,Account mnemonic as agreed between buy and sell sides
2,AdvId,String,Unique identifier of advertisement message.
3,AdvRefID,String,Reference identifier used with CANCEL and REPLACE transaction types.
4,AdvSide,char,Broker’s side of advertised trade
5,AdvTransType,String,Identifies advertisement message transaction type
6,AvgPx,Price,Calculated average price of all fills on this order.
etc
All,
Question 1:
Is there are any usage statistics for FIX by version.
Really, what I want to know is what version of FIX (4.2, 4.4, 5.0) has the highest number of users / is being used the most for exchange connectivity?
I have a feeling that it is 4.4. I would be inclined to say that there are more 4.2 users than 5.0. But, that is just a guess.
Question 2:
Is there a supported/verified/vetted downloadable file/repository containing the FIX Data Dictionary information in a non-XML format?
I would be ecstatic if someone can point me to a CSV (or similar) file with the following fields:
Tag,FieldName,Required ,DataType,Description/Comments
Int,String ,Char or Bool,String ,StringI’ve looked at FIXwiki’s repository. The last update was in 2009 - too old for my liking.
I don’t want to pull it off some random website I found as the effort to validate the data is just a little less than the mind numbing process of cut-and-paste from the FIX Protocol documentation (word docs) downloadable from this site.
Any and all comments/hints/questions (and yes) criticism greatly appreciated.
Ima
Here is a little XSLT file which can be used to produce data you require in CSV form:
<?xml version="1.0"?><xsl:stylesheet version=“1.0” xmlns:xsl=“XSLT Namespace”>
<xsl:template match=“Field”>
<xsl:value-of select=“Tag”/>,<xsl:value-of select=“Name”/>,<xsl:value-of select=“Type”/>,<xsl:value-of select=“Description”/>
</xsl:template>
</xsl:stylesheet>You just apply the above XSLT to the Fields.xml file of the FIX repository.
You could use, for example, the free command line tool “xsltproc” to do this.
Assuming that you have saved the above in a file called test.xslt and that the Fields.xml file is also in the current directory, just type the following:
xsltproc test.xslt Fields.xml
I really liked the fact that you provided a simple example illustrating how to make use the FIX Repository. A set of examples for some basic use cases is something I’ve always found lacking.
Your example only interacted with the Fields.xml file. I would love to see a similar example xslt that would list all of the fields and data types for a given FIX Allocation message (4.4 Confirmation (AK)) inclusive of iterating through nested component blocks. I’m just not an xslt wiz, so I don’t know how difficult that actually would be. (Or point me to other resource examples) Thanks in advance.
I’m not much of an XSLT expert. I agree that some more useful examples would be helpful. Can anyone else help us out here?
John
I really liked the fact that you provided a simple example illustrating how to make use the FIX Repository. A set of examples for some basic use cases is something I’ve always found lacking.
Your example only interacted with the Fields.xml file. I would love to see a similar example xslt that would list all of the fields and data types for a given FIX Allocation message (4.4 Confirmation (AK)) inclusive of iterating through nested component blocks. I’m just not an xslt wiz, so I don’t know how difficult that actually would be. (Or point me to other resource examples) Thanks in advance.
FIX is free to use and does not require any central registration. Hence there are no official statistics in terms of FIX versions. My guess is that clearing (post-trade) and market data tend to use FIX 5.0 and above whereas the classic FIX engines for trading still use FIX 4.x. You can get some information from http://www.fixprotocol.org/adopters/ but those are just the FPL members that fund, amongst other things, extensions to the FIX family of standards.
The FIX repository has grown extensively in the last few years and requires funding. FIX 4.2 had around 450 fields whereas we are now approaching the 2000 mark. As a non-FPL member, it is therefore currently only possible to obtain the 2008 edition of the repository which contains the complete set of FIX 4.x versions. The new repository is provided as a value to FPL members and updated with every Extension Pack, of which there are currently about 160. This is a major effort on the part of FPL. You will not need these updates if you provide only FIX 4.x. Older versions of FIX are not extended.
Your name and company indicate that you would like to stay anonymous. There is nothing to be afraid of and you will probably get more feedback if you are willing to share your identity. My comments above are also intended to inform others that may have the same questions as I believe they are very valid. FPL is not in a position to force people off of older versions. Decisions to upgrade are made whenever there is a business case to do so. New features are only offered with newer versions but not everybody needs them. Exchanges may be offering to support all of the versions mentioned below to accommodate different user types. The version is less important than the functional breadth supported by FIX interfaces. Usage of tags from higher versions or usage of user-defined fields clearly show that the majority of FIX interfaces out there are actually FIX 5.0 interfaces from a semantic point of view. They just happen to be “downgraded” to FIX 4.x from a technical point of view to avoid a mismatch of versions between counterparties.
Regards,
Hanno.
All,
Question 1:
Is there are any usage statistics for FIX by version.
Really, what I want to know is what version of FIX (4.2, 4.4, 5.0) has the highest number of users / is being used the most for exchange connectivity?
I have a feeling that it is 4.4. I would be inclined to say that there are more 4.2 users than 5.0. But, that is just a guess.
Question 2:
Is there a supported/verified/vetted downloadable file/repository containing the FIX Data Dictionary information in a non-XML format?
I would be ecstatic if someone can point me to a CSV (or similar) file with the following fields:
Tag,FieldName,Required ,DataType,Description/Comments
Int,String ,Char or Bool,String ,StringI’ve looked at FIXwiki’s repository. The last update was in 2009 - too old for my liking.
I don’t want to pull it off some random website I found as the effort to validate the data is just a little less than the mind numbing process of cut-and-paste from the FIX Protocol documentation (word docs) downloadable from this site.
Any and all comments/hints/questions (and yes) criticism greatly appreciated.
Ima
John and Hanno,
Thank you for your responses. They are helpful.
The FIX usage question was motivated because I have some spare time and thought I would spend it learning about FIX. I understand there is little difference between the various protocol versions but thought if I was going to spend time learning about FIX I might as well be with the version with the largest user base.
The second question was asked because what better way to learn about FIX messages than to create a FIX message parser/reader app. Yes, Yes I know these apps already exists, but for me, programming an app is much more interesting than reading volumes of documentation.
Again, Guys thanks for your responses.
Ima