Re: User Defined Messages Repository
Hanno Klein / Deutsche Börse Systems <>
4 May 2009 8:37AM ET
I do not believe that a repository of user defined messages would be beneficial to the standard. People always choose the path of least resistance. Why should I try to convince FPL committees of the usefulness of a message if I can simply post it to the public without such approval? I would not blame people for doing this as it is human nature but FPL should not create the means to do it.
I have similar concerns with the user defined fields even if the level of granularity is very different and one can quite easily answer the question "Is this field useful for me?". In case of a user-defined message, the answer is almost always going to be "Yes, maybe, but I would also need a few more (standard) fields in it". It gets really nasty when people re-define standard messages in their own flavor as user-defined messages. People would do that whenever they do not like the underlying transaction, state or identification models of FIX.
Not all fields are of equal importance. That is where my concerns about user-defined fields comes from. A single standard field like ExecType (150) or OrdStatus (39) conveys an entire state model. Adding user-defined fields can distort the intended semantics of a message. User-defined fields that convey additional attributes of an entity are not the problem as they have no impact on other fields or on the message flow. For example, adding a user-defined field expressing the quantity to be canceled to the OrderCancel message is technically no different than any other user-defined field. However, it suddenly allows partial cancelations of an order which was supported in the early days of FIX but then discarded. Mis-use is just too easy, already on a field level.
It only gets worse on the message level as you can then circumvent mandatory fields which FPL might have deemed key for a given message. You can just redefine NewOrderSingle and call it OrderEntry.
The whole idea of the FPL community is to come together in working groups and committees to discuss, among other things, gaps in the current spec and how best to close them. This is the only way that new messages, fields or enum values make it into the spec. Many user-defined fields are by now obsolete, yet the owners do not come forward to have them removed from the website. They have long solved their problem. Other have come forward with proposals that happen to cover some of the user-defined fields.
Let's be realistic, user-defined messages would not be added to the standard other than by the owner himself. The process for that is well established, i.e. participate in a working group or committee, write a gap analysis, have it posted, discussed, modified and finally approved by the GTC. Compared to SWIFT the process is very lean. People making a living with FIX should also support FIX by being a member and donating time and effort through participation. It takes more time than the design of a proprietary message but that is a price to pay for a standard that automatically benefits many.
There is enough mis-use of standard FIX messages and fields out there. I lean more towards not posting user-defined fields than towards also posting user-defined messages. The concepts as such make sense and should be kept. I doubt the actual degree of re-use beyond the submitter. Some fields are merely placeholders and serve no purpose for others.
Anyway, that's my opinion, but I believe the purpose of this thread was to collect views on this subject.
> Similar to "User Defined Fields Repository" at
> 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.
> K. Mahesh