[This message was posted by Jim Northey of The LaSalle Technology Group <[email protected]> to the "Website Feedback" discussion forum at http://fixprotocol.org/discuss/38. You can reply to it on-line at http://fixprotocol.org/discuss/read/5c880d0f - PLEASE DO NOT REPLY BY MAIL.]
Customization and the resultant non-uniformity (in my opinion not the opinion of FIX Protocol Ltd.) lessen the value of FIX to the overall FIX community (using economic terminology the non-uniformity creates a negative externality). The flexibility of FIX and the ability of customization are valuable indeed but they come at a cost - I prefer to look at them as a very necessary evil. Why do people need custom fields and custom messages? Because 1) the lead time in obtaining official tag numbers and new messages takes longer than the time available OR 2) the need identified is not considered a valuable or proper direction for the FIX Protocol (as decided by the GTC) OR 3) they have proprietary extensions that for reasons of privacy or competitive advantage they do not want to standardize or publicize (algorithmic trading tags for instance). Regarding #1: Under the leadership of Kevin Houston and Matt Simpson as GTC Co-chairs, we put in place the extension pack process and a proposal process that streamlines the time from a request to the issuance of tag numbers and message types. We have a process that we used even this week to issue tag numbers officially to avoid the requirement for user defined fields and enumerations. The automated specification build process which was created using FPL member funds now automatically creates a repository, FIXimate, and a FIXML Schema for each extension pack. Once we begin publishing extension packs to the website (starting next week) - members will receive the full value of this full process originally conceived by Kevin and Matt back in 2005. So we think we have an approach that addresses issue #1 appropriately. Regarding #2: I don't think it is necessarily a good idea for the FIX community as supported by FPL to provide a simple easy solution for publishing custom messages and fields. FPL should instead be focused on encouraging uniform adoption and expanding the standard in a commonly agreed upon way as needed. Providing a simple way to publish custom messages rewards and reinforces divergence not uniformity. Additional point: Custom messages in order to work an match the standard are identified as U1, U2, .... Now everyone that implements a custom message starts at U1. So we probably have 100 different custom U1 messages out there. What benefit does it provide listing 100 U1 messages? As a result we don’t see the value in providing this inventory on the FPL website. So from my perspective as a member of the FIX community - I would much prefer to see us use our very limited resources (of the 10,000 or so firms that use FIX only 197 have seen fit to support the FIX Protocol) on improving the uniform use of FIX than to take members' money to facilitate divergence and customization (Again I want to reiterate - this is my opinion and not the opinion of FIX Protocol Ltd.). > Similar to "User Defined Fields Repository" at > > http://fixprotocol.org/specifications/fields/5000-5999 > > a "User Defined Messages Repository" would be useful. We can know > for what purposes custom messages are being used and those messages > which are found useful can be added as standard FIX messages to > newer versions. > > Regards, > K. Mahesh [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
