This code is an attempt to create a reference implementation of the translation between tag=value and FIXML. It attempts to correctly convert valid messages, but it doesn't pay detailed attention to what is valid and what is not. It will spot and reject certain invalid messages, but not all (use the FIXML XSDs to confirm the validity of the message). It is not performance optimised, but does use appropriate datastructures (such as hash maps) to avoid obvious problems.
The definition of the FIX protocol is held in the FIX Repository, and recently (as of 2009 onwards) there has been a new and easier to use version of this known as the Unified FIX Repository. This is known to be the strategic direction.
Vendor supplied tools can import, amend and export this format. They can also generate FIXML XSD schemas from it.
The Unified FIX Repository is therefore the ideal configuration from which to drive FIX tools, such as this FIX Converter (and indeed, an earlier attempt to write a FIX Converter driven off of the FIXML XSDs failed when it was realised that information relating to repeating groups and other areas is missing).
In the Unified FIX Repository, we observe and expect the version element be the combination of major version, minor version, optional service pack and optional extension pack, and thus to align with these examples :-
The customVersion element is freeform, and sometimes when displaying diagnostic information, the FIX converter presents the full version as version/customVersion.
FIX has at least two representations: tag=value and FIXML.
tag=value is a compact representation, a typical message might start with :-
8=FIX.4.4<SOH>9=176<SOH>35=D<SOH>49=AFUNDMGR<SOH>56=ABROKER<SOH>34=521...
where <SOH> is ASCII character 1.
FIX Engines typically speak tag=value over network links between each other.
The FAST wire protocol is a compressed version of the tag=value format. We could imagine other compressed variants of tag=value, perhaps using ASN.1, but note that some of the FIX HFT discussion recently has proposed a number of measures that result in a different protocol rather than a different representation of the current protocol.
FIXML is an alternative XML based representation of FIX. A typical example might look like this :-
<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>
FIX in this representation can be easier to process, due to the ready availability of standard and open XML tools.
Many corporate messaging systems are XML based, in order to handle ISO 20022, FpML, XBRL and SWIFT (as MT/XML). Being able to represent FIX as FIXML can enable the processing of FIX by these messaging systems.
This further enables the use of the FIXML XSDs for message validation, the use of XSLT, Schematron or ISO Schematron for cross-field validation, and even the use of XQuery rules for cross-field validation. Routing and triggering based upon XPath expression is also enabled.
The use of FIXML instead of tag=value is usually at a non-trivial performance cost, and may not be for everyone. Therefore FIXML may play less in the pre-trade space, and more in the post-trade space.
Prior to FIX.4.4, the FIXML representations are defined by DTD, not by XSD. The Unified FIX Repository annotates them with fixml="0" suggesting that schemas shouldn't be generated from it. These earlier forms of FIXML seem to use elements where the modern form uses attributes.
This converter only understands valid FIXML as of version 4.4 onwards. The example shown previously is an example of this, and a good way to spot such messages is to note that the CompIDs are SID and TID attributes of the Hdr element. Unfortunately, the FIX Converter doesn't support the older 4.2 style of FIXML.
If you were to add metadata to the FIX.4.2 entry in the Unified FIX Repository, you could generate FIXML schemas in the new 4.4 style (although of course, these wouldn't match the official 4.2 DTD). FIX Converter would then be able to handle this alternative XML representation of FIX.4.2. It would also be necessary to ensure messages didn't directly include repeatingGroups, but instead used componentRefs to components containing repeatingGroups.
Unfortunately, it is common practice to send FIX messages in which the elements are not in the appropriate FIX namespace (or any namespace for that matter). The next two examples break the rules in this way. FIX Converter can cope with this (versioning related constraints below). It always generates FIXML with the right namespace.
http://fixwiki.fixprotocol.org/fixwiki/FPL:FIXML_Syntax has a couple of FIXML examples, reproduced here.
It shows an example of "FIXML 4.2 Version", which is somewhat verbose. A good way to spot such messages is that they have a FIXMLMessage element and the CompIDs are CompID elements within Sender and Target elements. The example looks 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>
Note that in the example, the SendingTime should actually be 2002-01-03T12:00:01.
The wiki also shows something it calls "FIXML 4.4 Schema Version". However, in the FIXML 4.4 schema, the CompIDs are not elements called Sndr or Tgt, they are attributes called SID and TID of the Hdr element. The example therefore incorrectly looks like this :-
<FIXML>
<Order ClOrdID="123456" Side="2"
TransactTm="2001-09-11T09:30:47-05:00"
OrdTyp="2" Px="93.25" Acct="26522154">
<Hdr Snt="2001-09-11T09:30:47-05:00"
PosDup="N" PosRsnd="N" SeqNum="521">
<Sndr ID="AFUNDMGR"/>
<Tgt ID="ABROKER"/>
</Hdr>
<Instrmt Sym="IBM" ID="459200101" IDSrc="1"/>
<OrdQty Qty="1000"/>
</Order>
</FIXML>
Note that even the the fixml-schema-4-4-examples-20040109.zip file that can be downloaded from the FIX Protocol site include a file called PositionReportExample1.xml has this incorrect Hdr structure.
I have also seen variants of the above where the sender CompID element was called Snd instead of Sndr.
In fixml-schema-4-4-examples-20040109.zip the included AllocationInstruction.xml file has no namespace, has bad dates, and has the wrong repeating group structure.
As incorrect messages like this don't agree with the FIX Repository, or schemas generated from it, the FIX Converter doesn't support them.
Just as the SWIFT MT (a compact binary format) is transported over the SWIFT network between organisations and SWIFT MT/XML is sometimes transported between applications within an organisation, we can forsee FIX tag=value being spoken between organisations (such as brokers and fund managers) and FIXML being used within these organisations.