Imported from previous forum
Hello,
I’m writing a whitepaper and I’m interested to know if there are people who have used FIXML as an internal data structure to enable both FIX (and in the future FIXML) data exchange with trading partners, AND who have experienced significant decrease of TCO (esp. when dealing with many different customized versions of FIX), while keeping production-grade performance. If there is no hard numbers, I’m interested about estimates/ideas as well…
Just to be really unambiguous: I’m talking about using the usual FIX TAG=Value<SOH> format with the usual FIX session layer, but translating incoming FIX messages into FIXML before validation, transformation, and routing logic is applied. And vice-versa for outgoing FIX messages.
To me, it seems that the wide availability of XML technologies and expertise would make the business case obvious when developing from scratch a FIX gateway. For instance on the technology side: using XML Schema (when it’s available!) to perform declarative-style validation instead of proprietary grammars (ex. Euronext’s xml-based grammar: http://www.gca.org/papers/xmleurope2001/papers/html/s05-3.html
), Java/C++/C#/script APIs for more advanced validation, XSLT or XMLQuery for transformation, etc. would seem more cost-effective than proprietary data model/APIs/etc. And on the expertise side, it seems clear that XML expertise is cheaper than expertise in proprietary technologies. Last, such an approach would be quickly FIXML-ready with a SOAP or HTTP wrapper, when FIXML is finally embraced as a B2B messaging/serialization format.
What do you think?
Thanks
Guillaume
[ original email was from Chris Lambert - chris.lambert@cmg.com ]
Agree that is a priority area for TCO case studies - hopefully some will come up.
A related question is what is the impact of using ISO [15022] XML as an alternative to FIXML.