[Quickfix-developers] New Algo Std @ FIX, hot XML implementation
Brought to you by:
orenmnero
|
From: Rick L. <ri...@cl...> - 2007-04-23 16:42:29
|
Just wanted to give Quickfix developers a heads up on the rapidly emerging new algo standard at FIX, and ask for some specific feedback on two open issues. See http://www.fixprotocol.org/algostandard for the standard and the sample files. The FIX Algo committee would very much welcome QuickFix developer input into refining the standard into something that smoothly integrates with the rest of what you are doing with QuickFix in open source. The comment period ahead of pilot testing runs through April. After that pilot tests begin, the process starts to become significantly more rigid. We have a few open issues that are being worked on the work group. See the issues documents at the above address for the full listing. Here are two however that may be of specific interest to QuickFix developers I'll cover right here. Number one, as part of this algo draft standard, but also for other initiatives, FIX is in process of exposing all its XML (.xsd files) in a public directory, accessible on a file by file uncompressed basis, with no delay, no registrations -- wide open for all who come to get them. Each file will contain a comment similar to the following (in draft form): *** Copyright 2007 FIX Protocol Ltd. See usage license at: http://fixprotocol.org/copyright.shtml WARNING: Locally Cache These files! Numerous problems can impede access to these files on a timely basis, many of which are not controllable by FIX. Problems include, but are not limited to, network outages in any hop between FIX and your destination, file caching schemes deployed by various ISP along the route, name to IP number resolution and other DNS issues, router table error or corruption at any hop, FIX web server technical difficulty, network congestion on links or within routers, web server and back end database server loads, loads on servers located adjacent to FIX web servers, power failures, viruses and corruption, hardware failures, etc. FIX cannot be held responsible for any delays in your receipt of these files. Furthermore there is no guarantee that the files will not be changed in the future. Errors or inconsistencies may be introduced into these files at any time, even during the performance of minor maintenance. Changes to these files may be inconsistent with your implementation. There is no guarantee that version numbers on files will always increment with a minor change. FIX is not responsible for any usage of these files whatsoever. Also note that these files will not be made available indefinitely. It's currently planned that only frequently accessed files will remain available, generally the most current three versions or less. There is no guarantee that a historical achieve will be maintained or if one exists that it will cover all files ever issued by FIX. Do not rely on FIX to be a permanent backup to files essential to your operation. *** Obviously, the above is for legal purposed to protect FIX from damage claims in an outage. FIX intends however to operate highly reliable web servers with great connections, ample bandwidth, and be able to serve up the files whenever needed. Further, it's not intended that there will be a new Algo standard coming out of FIX any more frequently than every two or more years. Still, the algo area is volatile and rapidly evolving, so I think you can see where this may be headed. Question #1 what is your reaction to the above? Does this make life better or more miserable for a FIX engine developer? Any additional things we need to consider as more frequent updates to FIX become more specialized and frequent? (There are a number of extensions and service packs in the development cue at FIX.) Question #2 any thoughts on where we should be headed with validation? Here's the current "to be looked at" list: Schematron CLIX http://nrl.sourceforge.net/ http://www.omg.org/technology/documents/modeling_spec_catalog.htm#OCL http://www.ruleml.org/ It's likely we will not do anything other than the simplest validation -- a very basic and limited sub segment common across all of the above "rule engines" -- in Version 1.0 of the new algo standard. However after that ships we will be looking to tighten up this considerably as it's a huge area of miscommunication between Broker Dealer providers of algos and Order Management System / Buy Side users. Any ideas how best to do additional validation beyond which the base level of XML accomplishes? Comments and observations are very much appreciated. Anything sent to alg...@fi... will hit every member of the technical work group at FIX and be carefully considered. Thanks very much. The Fix Algorithmic Trading Working Group |