FIX <-> FIXML conversion - using XSDs

Imported from previous forum

I am testing the idea that FIXML can be converted to FIX tag=value and back, by reference to the FIXML XSD files.

I need to cope with FIX 4.2, 4.4, 5.0 and later.
I need to cope with the case where folks have added user defined elements with corresponding tags.

How practical do people think this is?
My initial investigations suggest I can see that 90% of the job can be done, I’m wondering about the rest.

Observations:

I’m referring to what looks like official FIXML 4.4 schema.
There is an x: prefixed namespace, for FIX metadata.
I see xs:Xref tags, some of which have tag= attributes.
It looks like these should really be x:Xref (and I certainly see x:EnumDoc elsewhere).

I haven’t seen a linkage between tag 35 (the message type) and the specific derivation of Message (eg: NewOrderSingle) - any idea how this could be done?
Will I have to supplant the information in the XSDs with additional mapping tables?

Looking at what looks like official FIX 5.0 SP2 schema.
There is a fm: prefixed namespace, for FIX metadata.
fm:Xref and fm:EnumDoc elements exist.
There is <fm:Xref … name=“MsgType” Tag=“35” …/>

{{{ Andy

We modified the metadata between versions to improve quality and usability of the metadata. Not 100% sure we are yet providing enough information to use the XSD as your tool for translation. The FIX Repository might be a better place to start.

This would be a nice example application to provide FPL members for repository / FIXML Schema. A tool to mechanically translate between FIX and FIXML.

I am testing the idea that FIXML can be converted to FIX tag=value and back, by reference to the FIXML XSD files.

I need to cope with FIX 4.2, 4.4, 5.0 and later.
I need to cope with the case where folks have added user defined elements with corresponding tags.

How practical do people think this is?
My initial investigations suggest I can see that 90% of the job can be done, I’m wondering about the rest.

Observations:

I’m referring to what looks like official FIXML 4.4 schema.
There is an x: prefixed namespace, for FIX metadata.
I see xs:Xref tags, some of which have tag= attributes.
It looks like these should really be x:Xref (and I certainly see x:EnumDoc elsewhere).

I haven’t seen a linkage between tag 35 (the message type) and the specific derivation of Message (eg: NewOrderSingle) - any idea how this could be done?
Will I have to supplant the information in the XSDs with additional mapping tables?

Looking at what looks like official FIX 5.0 SP2 schema.
There is a fm: prefixed namespace, for FIX metadata.
fm:Xref and fm:EnumDoc elements exist.
There is <fm:Xref … name=“MsgType” Tag=“35” …/>

{{{ Andy

Jim, thanks for the reply. I know we have spoken about this in the past. :slight_smile:

The attraction of using the XSD schemas is that they convey the STRUCTURE of the FIXML message, as well as the relationship between attributes and tag values.
And also, that XSD (admittedly with Xrefs) is hopefully more stable than the FIX Repository. :slight_smile:

It also seems that people generating the XSDs, and writing the tools which generating the XSDs are going to lengths to try to inject as much as they can from the repository, via Xref and EnumDoc.
This is very helpful.

What I have seen is that certain sets of XSDs don’t have all the tags in them (eg: FIXML 4.4 schemas don’t have MsgType, ie: tag 35, but 5.0 SP2 does).
I have also seen certain unofficial 3rd party tool generated schemas having unexpanded ${tokens}, which I guess to be related to missing data in the repository that the generation process is working from.
I have also seen namespace problems for the Xref elements themselves (but I can cope with that).

Working from the repository itself might be more tractable for someone that knows the repository (and its history of evolution) in detail, but alas, my knowledge of XSD is much better.

I might also add that we need XSD for validation purposes, so if we can reuse the same assets for conversion, we simplify things for our data architects and operational staff.

I agree that a standard reference implementation (along with a standard test-pack of FIX and FIXML message pairs) would be very useful to everyone.
(I note that SWIFT deliver this already in their SDK for MT FIN <-> MTXML conversion).
All I can find thus far are samples (with disclaimers), sometimes with novel approaches (eg: one using XSLT and an intermediate XML implementation for example), not necessarily current or complete, with no way to verify their currency or completeness.

{{{ Andy