Imported from previous forum
One of the topics we need to address during the next meeting of the repository working group is how we begin to modify the structure of the repository to include additional content. Somethings we can do easily. We are adding version related metadata - both via contributions from John Cameron and by some of our own internal work. The issue becomes adding new elements for enumeration description, enumeration naming. 1. Do we just modify the structure and provide a backward compatible set of files? This is the way I am leaning after exchange emails with Russ Curry. 2. Or do we move to the unified repository which addresses the issues and does so in a format that supports multiple versions of FIX and is structured in a more XML format as opposed to a database table format. 3. Or do we keep the base the same and keep the new information separate. In terms of work to modify the build process and all the generators for FIXimate, FIXML Schema, MSWord, Extension Pack (EP) compiler, etc. I think 1 and 3 are about the same level of effort. But 3 adds in an extra set of data files. #2 is the most work in that we would need to change most of our generators and would have to change the EP Compiler (FYI - the EP Compiler was created to separate the change format from the underlying repository format) so change in this area was anticipated in the design. My personal thoughts are to go with 1 and to begin to modify the original format - keeping the separate table file structure and then add a very simple XSLT that can produce a backward compatible set of files (per Russ's suggestion) and continue to generate the unified repository from the base. Other input and suggestions are greatly appreciated.
I’m happy to go with your recommendation and go with option 1.
I kind of like the table structure and the code I have written for FIXwiki is designed to use it.
One of the topics we need to address during the next meeting of the
repository working group is how we begin to modify the structure of the
repository to include additional content. Somethings we can do easily.
We are adding version related metadata - both via contributions from
John Cameron and by some of our own internal work. The issue becomes
adding new elements for enumeration description, enumeration naming.
Do we just modify the structure and provide a backward compatible set
of files? This is the way I am leaning after exchange emails with
Russ Curry.Or do we move to the unified repository which addresses the
issues and does so in a format that supports multiple versions of
FIX and is structured in a more XML format as opposed to a
database table format.Or do we keep the base the same and keep the new information
separate.In terms of work to modify the build process and all the generators for
FIXimate, FIXML Schema, MSWord, Extension Pack (EP) compiler, etc. I
think 1 and 3 are about the same level of effort. But 3 adds in an extra
set of data files.#2 is the most work in that we would need to change most of our
#generators and would have to change the EP Compiler (FYI - the EP
#Compiler was created to separate the change format from the
#underlying repository format) so change in this area was anticipated
#in the design.My personal thoughts are to go with 1 and to begin to modify the
original format - keeping the separate table file structure and then add
a very simple XSLT that can produce a backward compatible set of files
(per Russ’s suggestion) and continue to generate the unified repository
from the base.Other input and suggestions are greatly appreciated.
I do not have a strong opinion on any of the options and support whatever those more familiar with the detailed structure recommend. I certainly would like the ability to add descriptions for enumerations as there is just too little information on enum values today. The FIXwiki offered by John Cameron has such a feature which is great. It reduces the level of interpretation people can apply and increases the chances of (proper) usage. Often enough, an enum value is not used at all because the term is not identical to the one in use at a firm. The standard should not support various terms for the same semantic but chose a single term and list alternate terms in its description.
The semantic can often only be captured by the description as a term is typically short. For example, it does not matter whether a trading subsession is called “Regular”, “Trading”, “Normal Trading”, or “Continuous Trading”, all terms convey the same semantic of the subsession during which the bulk of the trading occurs. Currently, only the rules of engagement can explain the standard enum values by adding “local” terms.
One of the topics we need to address during the next meeting of the
repository working group is how we begin to modify the structure of the
repository to include additional content. Somethings we can do easily.
We are adding version related metadata - both via contributions from
John Cameron and by some of our own internal work. The issue becomes
adding new elements for enumeration description, enumeration naming.
Do we just modify the structure and provide a backward compatible set
of files? This is the way I am leaning after exchange emails with
Russ Curry.Or do we move to the unified repository which addresses the
issues and does so in a format that supports multiple versions of
FIX and is structured in a more XML format as opposed to a
database table format.Or do we keep the base the same and keep the new information
separate.In terms of work to modify the build process and all the generators for
FIXimate, FIXML Schema, MSWord, Extension Pack (EP) compiler, etc. I
think 1 and 3 are about the same level of effort. But 3 adds in an extra
set of data files.#2 is the most work in that we would need to change most of our
#generators and would have to change the EP Compiler (FYI - the EP
#Compiler was created to separate the change format from the
#underlying repository format) so change in this area was anticipated
#in the design.My personal thoughts are to go with 1 and to begin to modify the
original format - keeping the separate table file structure and then add
a very simple XSLT that can produce a backward compatible set of files
(per Russ’s suggestion) and continue to generate the unified repository
from the base.Other input and suggestions are greatly appreciated.