Imported from previous forum
[ original email was from John Harris - john.harris@bondmart.com ]
We discussed on the last call the importance of promulgating principles that future specifications should follow. At least in theory, if we can agree on a proper set of principles, we need only compare future specification proposals against the guiding principles to determine whether said proposals are consistent and therefore are candidates for incorporation in specifications.
I would suggest that making a sincere effort toward establishing these principles is worth a significant effort and amount of time, on grounds that the investment we make now will pay significant dividends later.
So, let me start out with a few suggestions, making no assertion as to completeness or proper ordering (in fact, I am sure these are incomplete and improperly ordered):
– All specifications and related documentation and data stores (“FIX Specifications”), whether draft, published for comment, or final, shall be accessible to all interested parties on equal terms, free of charge, whether in downloadable or screen-viewable form. Notwithstanding this provision, FPL may sell specifications and related documentation in printed form or on magnetic or optical media on a non-discriminatory basis, whether to recover costs or assist with the funding of its operations.
– Licensing of all FIX Specifications and contributions to FPL of ideas, writings, etc. by any person shall be standardized, using one or more widely-adopted, open, free-of-charge protocols such as those promulgated by Creative Commons.
– All FIX Specifications should themselves adhere to a specification (or “style guide”) as to form, language, grammar, usage conventions, etc.
– All FIX Specifications should be published, at minimum, in a standard hypertext format and available for indexing by search engines.
– Access to discussion forums and other collaborative tools and systems may be restricted on the basis of membership status or role (e.g., “volunteer”).
– All FIX Specifications shall be correct and as concise as possible, their authors ensuring that (1) business people with modest technical knowledge can understand them and (2) engineers can rely on them to build working products and services (e.g., “FIX engines”).
– In developing specifications authors shall bear in mind the cascading and magnifying effects of errors, incompleteness, inconsistencies, and ambiguities. That is, they must bear in mind that for want of one minute of extra care in producing a specification, they may cause months or years of extra work (whether individually or in aggregate) for those trying to follow their specifications.
– While FIX Specification authors should provide helpful examples of proper implementation to aid comprehension, they should leave pedagogy to others.
– To the greatest extent possible trade-related FIX messages should avoid reliance on, and eschew transport of, what we know in our business as “reference,” “static,” or “fundamental” data. Instead, as necessary, trade-related FIX messages should contain pointers or references to this data. This is not to preclude the use of FIX to encode such data for use in seeding and updating data stores or for similar purposes.
– To the greatest extent possible FIX Specifications should rely on other widely-adopted, well-conceived standards (e.g., ISO standards), but only to the extent those standards are also accessible on licensing terms substantially similar to those adopted by FPL. (We should not, in other words, require reliance on a list of exchange codes or instrument identifiers that are not freely accessible on terms similar to those adopted by FPL).
– FIX Specifications should be crafted in such a way that the need for “implementation specifications” is minimized if not eliminated.
Elaboration and criticism of these suggested principles is most welcome.