[Quickfix-developers] New Algo Std @ FIX, hot XML implementation

[Rick L. <ri...@cl...>]

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