Imported from previous forum
[ original email was from Jianhua Sun - jianhua.sun@csfb.com ]
The release of 4.2 increase the number of protocols from 141 (4.1) to 441. that is really great.
However, as a programmer, I feel more defficult to implement as the protocols grow more and more. My question is, could the specification be divided into a base and multiple extensions? like in X protocols? this would make it easier for many sites that only concern part of the protocol implemention and still without losing a standard.
When one site say they support one of the extension, it means the extension is fully supported. So any site would talk to the other site if both site support that extention.
I am relatively new in this field and am not quite sure if this is feasible (or even reasonable?, specially when the specification already has 441 defined).
J. Sun
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> The release of 4.2 increase the number of protocols from 141 (4.1) to 441. that is really great.
>
> However, as a programmer, I feel more defficult to implement as the protocols grow more and more. My question is, could the specification be divided into a base and multiple extensions? like in X protocols? this would make it easier for many sites that only concern part of the protocol implemention and still without losing a standard.
> When one site say they support one of the extension, it means the extension is fully supported. So any site would talk to the other site if both site support that extention.
While I don’t necessarily see a problem with splitting the enormous document into smaller pieces (i.e. Message Format and Session, Order entry, Pre-Trade IOIs / Advertisements, etc.) I think that requiring an all-or-nothing approach on implementation of everything within an extention is not practical.
The issue is that people choose to implement a protocol based on their business needs, and in general can’t re-architect their business around a protocol. Numerous optional fields have been added to the spec with the understanding that they enable features for thoes who need them but do no harm to those who wish to ignore them. Many implementations are FIX-compliant for the subset of the spec they choose to implement, but don’t implement everything, even within a category such as order entry. For instance, some firms may not implement status requests, others may not implement cancel / replace. Their order management systems may not even have similar concepts for some of these things, hence implementing everything isn’t really option.
It is my belief that any FIX certification process should take this into account, so that even within one extension (i.e. order entry) there would need to be several optional sub-extensions (i.e. cancel/replace, status requests, GTC order processing, “unsolicited” order restatement). This means that determining interoperability isn’t just as simple as looking for a FIX certification mark; it would mean examining a certified capabilities matrix to make sure that both parties are certified for all of their business needs. At the same time, I believe such granularity allows for more people to certify, as it reduces the burden of implementing numerous capabilities that don’t make sense for a given business application.