Imported from previous forum
I am considering whether it is practical to build a FIX <-> FIXML converter that uses the FIX Repository as its configuration.
(I am also considering whether the FIXML XSDs could be used, but its starting to look like these have insufficient information, such as repeating group tag information).
The older FIX repository (a collection of several XML files) seems to regularly change in terms of the number of files, their content and the element/attribute names.
The newer “Unified” FIX repository looks quite a bit nicer to work with.
However, even here, I have only found two versions (FIXRepository-2009-Edition and FIXRepository-2010-Edition_rel-20100620), and these differ in their structure.
The 2010 copy (only) includes FIXRepository.xsd, but the 2009 version of FIXRepository.xml does not validate against it.
So my question is around the STABILITY of the Unified repository as something to code against.
I’d expect it to be in everyones (standards provider, tools vendors, people like myself) interest that it be stable.
What can we realistically expect going forwards?
Has most of the work on its structural form done, and all we get now is new content?
Or do we get small incremental additions to attributes (eg: add FIXML xv= attribute)?
Or do we get structural rework?
Phrased another way, if I code something that reads the repository (perhaps with JAXB), will I have to recode it every yearly Edition?
(Yes, I am aware of the 2010 to 2009 migration scripts, and in principle if I wrote code this year, and got the 2012 Edition, I could use 2012->2011 and 2011->2010 scripts).
{{{ Andy
Andy,
Right now as you have discovered it is not possible to perform FIX to FIXML conversion using the Schema because the metadata section is incomplete, not to mention the complexities of reading the schema.
The choice in using FIX Repository is the best approach. The Unified Repository is most likely our strategic direction (I don’t want to overstep and put out a policy statement that must necessarily be driven by the Repository WG and approved by the GTC Governance Board).
In terms of 2010 Unified Repository interface stability, my perspective is that we should be able to commit to backward compatibility, meaning that any application written to the 2010 format, as long as it can ignore additional higher level elements (for rules, profiles, etc.) and additional attributes I believe we can make this commitment to the community. Of course, I cannot make this commitment, but we can put this on the agenda of the Repository Working Group as well for official approval.
There are also some rules in terms of how to generate FIXML Schema from the FIX Repository that we should publish as part of the repository to assist those doing higher level model driven / enterprise architecture approach to integration of financial messaging protocols.
I think I can speak for the FIX Community and say that we would welcome and support your work on a FIX to FIXML converter library.
I am considering whether it is practical to build a FIX ↔ FIXML converter that uses the FIX Repository as its configuration.
(I am also considering whether the FIXML XSDs could be used, but its starting to look like these have insufficient information, such as repeating group tag information).The older FIX repository (a collection of several XML files) seems to regularly change in terms of the number of files, their content and the element/attribute names.
The newer “Unified” FIX repository looks quite a bit nicer to work with.
However, even here, I have only found two versions (FIXRepository-2009-Edition and FIXRepository-2010-Edition_rel-20100620), and these differ in their structure.
The 2010 copy (only) includes FIXRepository.xsd, but the 2009 version of FIXRepository.xml does not validate against it.So my question is around the STABILITY of the Unified repository as something to code against.
I’d expect it to be in everyones (standards provider, tools vendors, people like myself) interest that it be stable.
What can we realistically expect going forwards?Has most of the work on its structural form done, and all we get now is new content?
Or do we get small incremental additions to attributes (eg: add FIXML xv= attribute)?
Or do we get structural rework?Phrased another way, if I code something that reads the repository (perhaps with JAXB), will I have to recode it every yearly Edition?
(Yes, I am aware of the 2010 to 2009 migration scripts, and in principle if I wrote code this year, and got the 2012 Edition, I could use 2012->2011 and 2011->2010 scripts).
{{{ Andy
Hello Andy
We have built a FIX ↔ FIXML conversion package that we use to integrate with external message buses (such as EMS) and middleware platforms such as BizTalk.
We run the conversion directly off the FIX repository. We also had the issue of having to support different repository file formats and are looking to move over to the unified repository format.
There are some intricacies to be wary of such as having to sort repeating group attributes when converting from XML to FIX to be FIX tag-value compliant.
Clive
Andy,
Right now as you have discovered it is not possible to perform FIX to FIXML conversion using the Schema because the metadata section is incomplete, not to mention the complexities of reading the schema.
The choice in using FIX Repository is the best approach. The Unified Repository is most likely our strategic direction (I don’t want to overstep and put out a policy statement that must necessarily be driven by the Repository WG and approved by the GTC Governance Board).
In terms of 2010 Unified Repository interface stability, my perspective is that we should be able to commit to backward compatibility, meaning that any application written to the 2010 format, as long as it can ignore additional higher level elements (for rules, profiles, etc.) and additional attributes I believe we can make this commitment to the community. Of course, I cannot make this commitment, but we can put this on the agenda of the Repository Working Group as well for official approval.
There are also some rules in terms of how to generate FIXML Schema from the FIX Repository that we should publish as part of the repository to assist those doing higher level model driven / enterprise architecture approach to integration of financial messaging protocols.
I think I can speak for the FIX Community and say that we would welcome and support your work on a FIX to FIXML converter library.
I am considering whether it is practical to build a FIX ↔ FIXML converter that uses the FIX Repository as its configuration.
(I am also considering whether the FIXML XSDs could be used, but its starting to look like these have insufficient information, such as repeating group tag information).The older FIX repository (a collection of several XML files) seems to regularly change in terms of the number of files, their content and the element/attribute names.
The newer “Unified” FIX repository looks quite a bit nicer to work with.
However, even here, I have only found two versions (FIXRepository-2009-Edition and FIXRepository-2010-Edition_rel-20100620), and these differ in their structure.
The 2010 copy (only) includes FIXRepository.xsd, but the 2009 version of FIXRepository.xml does not validate against it.So my question is around the STABILITY of the Unified repository as something to code against.
I’d expect it to be in everyones (standards provider, tools vendors, people like myself) interest that it be stable.
What can we realistically expect going forwards?Has most of the work on its structural form done, and all we get now is new content?
Or do we get small incremental additions to attributes (eg: add FIXML xv= attribute)?
Or do we get structural rework?Phrased another way, if I code something that reads the repository (perhaps with JAXB), will I have to recode it every yearly Edition?
(Yes, I am aware of the 2010 to 2009 migration scripts, and in principle if I wrote code this year, and got the 2012 Edition, I could use 2012->2011 and 2011->2010 scripts).
{{{ Andy
Clive, thanks for your reply.
I can also report I have made progress with this, working directly off of the 2010 Edition of the Unified FIX Repository.
I think I’ve found a couple of things I might want clarifying / adding in the next Edition, but basically I’m happy its do-able.
My next challenge is sourcing messages I can use to test with.
Yes, I’ve found quite a few intracacies and gotchas in the process, around tag ordering, repeating groups, versioning, message categories and XML attribute names, encoded tags, len+data tag pairs, old style FIXML samples that don’t seem to match the schemas, etc…
I’ll share more in the future…
{{{ Andy
Clive, another question:
I note what I think are older FIXML 4.2 examples in which the Sender CompID is in an element called //Sender/CompID, and I note that some newer FIXML 4.4 examples and schemas use an attribute @SID in the element.
Do you bother to support the translation between old-style FIXML and tag=value?
All I care about is tag=value between organisations and an XML representation internally.
So I’m thinking should I simply convert FIX 4.2 tag=value into new-style FIXML (ie: using attributes) for internal use, rather than the official old style FIXML.
Obviously I’d need to add all the FIXML information to the Unified FIX Repository, but it seems simpler than coding 2 different FIXML<->tag=value converters.
One obvious advantage is that some of the XPaths or (non-namespace aware) binding code I use to process the FIX messages could be shared and be non-version specific.
{{{ Andy
Hi Andy,
We don’t specifically support that format in our converter tools (i haven’t come across it with any of the counter-parties we have connected to).
Our conversion process runs off the repository itself, but it does depend tags being formatted as XML attributes rather than elements.
Clive
Clive, another question:
I note what I think are older FIXML 4.2 examples in which the Sender CompID is in an element called //Sender/CompID, and I note that some newer FIXML 4.4 examples and schemas use an attribute @SID in the element.
Do you bother to support the translation between old-style FIXML and tag=value?
All I care about is tag=value between organisations and an XML representation internally.
So I’m thinking should I simply convert FIX 4.2 tag=value into new-style FIXML (ie: using attributes) for internal use, rather than the official old style FIXML.
Obviously I’d need to add all the FIXML information to the Unified FIX Repository, but it seems simpler than coding 2 different FIXML<->tag=value converters.
One obvious advantage is that some of the XPaths or (non-namespace aware) binding code I use to process the FIX messages could be shared and be non-version specific.
{{{ Andy