Retrofitting all the modern FIXML goodness from FIX.4.4 to earlier versions.
FIXML prior to FIX.4.4 used lots of elements. http://fixwiki.fixprotocol.org/fixwiki/FPL:FIXML_Syntax shows an FIXML 4.2 example like this :-
<FIXML>
<FIXMLMessage>
<Header>
<PossDupFlag Value="N"/>
<PossResend Value="N"/>
<SendingTime>20020103-12 00 01</SendingTime>
<Sender>
<CompID>AFUNDMGR</CompID>
</Sender>
<Target>
<CompID>ABROKER</CompID>
</Target>
</Header>
<ApplicationMessage>
<Order>
... stuff
</Order>
</ApplicationMessage>
</FIXMLMessage>
</FIXML>
It is thought that the old kind isn't often spoken between organisations.
FIXML from FIX.4.4 onwards uses fewer elements, and FIX fields are typically attributes. An example :-
<FIXML xmlns="http://www.fixprotocol.org/FIXML-4-4" v="4.4">
<Order ID="123456" Side="2" TxnTm="2001-09-11T09:30:47-05:00"
Typ="2" Px="93.25" Acct="26522154">
<Hdr Snt="2001-09-11T09:30:47-05:00" PosDup="N" PosRsnd="N"
SeqNum="521" SID="AFUNDMGR" TID="ABROKER"/>
<Instrmt Sym="IBM" ID="459200101" Src="1"/>
<OrdQty Qty="1000"/>
</Order>
</FIXML>
Various corruptions of the FIXML standards may be observed in the wild, including lack of namespaces and incorrect element names. Part of the problem may be in the lack of use of schemas to validate messages, either at design, development, testing or execution time.
Hypocritically, FIX Retro introduces another corruption of the FIXML standards, although this time (the author would argue), in a good cause. ie: trying to bring the legacy of the past upto date with the present.
The 2010 Edition of the Unified FIX Repository includes FIX.4.0 to FIX.5.0SP2.
Versions prior to FIX.4.4 have an fixml="0" attribute, and include no metadata facilitating the generation of the FIXML schemas.
Version from FIX.4.4 onwards have an fixml="1" attribute, and a whole load of extra metadata (such as abbrName, categories, category, baseCategoryAbbrName etc..) which support the generation of FIXML schema.
This probably reflects the fact that common FIX tooling only generates the FIX.4.4 onwards style of schema from the Unified FIX Repository.
FIX Retro reads the Unified FIX Repository. It locates the (non-customised) entry for FIX.4.4. It then looks for every old entry for a version of FIX with fixml="0". It augments each of these with information from FIX.4.4, and marks the entry with fixml="1". It also appends #RETRO to the specUrl attribute, so as to make it additionally clear something strange has happened.
FIX Retro copies the abbreviations, categories and sections elements from FIX.4.4.
It ensures that if the old version of FIX doesn't have a datatype that is present in FIX.4.4, then its copied from FIX.4.4. This is important as it ensures the old version of FIX gets a NumInGroup datatype.
If the old version of FIX has a field or component which is not present in FIX.4.4, then the abbrName used will match the unabbreviated name. eg: FIX.4.2 has tag 20 (aka ExecTransType) and FIX.4.4 does not.
If the old version of FIX has a field whose name is different to that in FIX.4.4, then a warning is displayed. The abbrName used will still be taken from FIX.4.4. eg: FIX.4.2 tag 22 is called IDSource, but in FIX.4.4 its known as SecurityIDSource.
If the old version of FIX has a field whose name starts with No, of type int, then this is corrected to be of type NumInGroup.
FIX Retro ensures the old version of FIX has a Hop component referencing NoHops, HopCompID, HopSendingTime and HopRefID fields, by copying these from the FIX.4.4 definitions. Lasalletech FIX Explorer 2.2.2 will not export valid FIXML XSDs without this being present in the version of FIX, even though no message or component uses the Hop component. This is completely understandable - all official FIXML versions have a Hop component.
If the old version of FIX has components or messages not present in FIX.4.4 then a warning is displayed. This doesn't happen, but if it did, it would mean that the resulting output file isn't complete, and would be unlikely to be usable.
FIX Retro also looks at components and messages to see if any of them directly include repeating groups. It creates a component containing the repeating group and replaces the repeating group in the message with a component reference. It does this because the modern FIXML relies on the fact repeating groups are children of components (all the fields in the group are attributes and have to have an element, defined by the component, to be attached to).
The XML element name for the repeatingGroup in the FIX.4.2 and FIX.4.3 Logon message cannot be determined from anywhere, so FIX Retro hard-codes the name RefMsg.
It looks through messages and repeating groups for sequences of fields which should actually be in components, which are then referenced. It uses FIX.4.4 as a guide as to what components should be used and what fields they should reference. This is necessary to ensure the resulting FIXML has a nicely nested structure of XML elements. If this is not done, you can end up with more than one field in a message or component wanting to use the same XML attribute name, which obviously can't be allowed.
Note that in FIX.4.3 the LegCurrency field sits alongside but not in the InstrumentLeg component. FIX Retro does not move it into the component, despite the fact that it is in the component in FIX.4.4.
After using FIX Retro, it should be possible to load the resulting Unified FIX Repository file into a tool such as Lasalle FIX Explorer and then generate schema for these earlier versions of FIX.
In particular, I care about FIX.4.2, as it seems to be still in widespread use.
This wouldn't result in the official FIXML schemas for FIX.4.2. It would result in schemas for FIX.4.2, created in the same style as the FIX.4.4 ones. Or put another way: FIXML 4.2 the way perhaps the FIXML designers had wished they had done it originally.
Despite not being the official FIXML 4.2, this alternative XML representation of FIX.4.2 is complete, and is potentially useful.
An example of what this looks like :-
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- This is not FIXML 4.2, it is an XML representation of FIX.4.2, in the modern FIXML 4.4 onwards style -->
<FIXML v="4.2" xmlns="http://www.fixprotocol.org/FIXML-4-2">
<Order Acct="26522154" HandlInst="1" ID="123456" Px="93.25" Side="2" TxnTm="2001-09-11T14:30:47" Typ="2">
<Hdr PosDup="N" PosRsnd="N" SID="AFUNDMGR" SeqNum="521" Snt="2001-09-11T14:30:47" TID="ABROKER"/>
<Instrmt ID="459200101" Src="1" Sym="IBM"/>
<OrdQty Qty="1000"/>
</Order>
</FIXML>
The FIX Converter runs off of the Unified FIX Repository and understands the FIX.4.4 onwards kind of FIXML. It will therefore be able to convert between FIX.4.2 tag=value and this alternative XML representation of FIX.4.2.
This enables a single XML based messaging system to cope with FIX.4.2 in the same way as it would FIX.4.4 onwards. Many XPath expressions will be virtually the same for all versions of FIX (apart from the namespaces), and similarly for any XSLT or XQuery based validation logic.