Imported from previous forum
Hello,
I’m working with the archived XML files which represent each FIX version. Working with the 4.3 version, I notice that the Fields.xml files contain the following possible two errors:
Tag 22: given as name “SecurityIDSource(formerly named: IDSource prior to FIX 4.3)”, should this be named SecurityIDSource, with the “formerly” phrase moved to the description part?
Tag 536: listed as of type Stirng, should this be String?
Tag 588: listed as of type LocalMMktDate, should this be LocalMktDate?
I’ve written code which reads these files to build a formal description which guides parsing, generation, and translation of FIX messages. With the 4.0, 4.1, and 4.2 files there are no problems, but the 4.3 files break the formalism in at least the ways mentioned above, limiting their usefulness for automated parsing even if they are adequate for generating the human-readable manuals.
Some additional information:
these errors were as expected propagated into the Word documents.
Another possible more serious error: field 604 (NoLegSecurityAltID)is listed as of type String in volume 6, similarly in the Fields.xml file. But in volume 1, and in MsgContents.xml, this field appears to be a repeating group count field, and thus should be of type int.
This field is (in vol 6) described as " Multileg instrument’s individual security’s NoSecurityAltID", and refers to field 454 (NoSecurityAltID), which is in fact correctly identified as an integral repeat count field.
Ideally, since I’m writing programs which run off these XML files, I would like to have the cleaned up. I am willing to provide help with this.
Thanks!
Roderick,
Thank you for reporting the issues - now that FIX.5.0SP2 we have started a repository maintenance project entitled “Repository Maintenenance Release 2009”. We are in the process of correct errors across several versions - we will address your issues as well.
Thanks for reporting the issues.
Best Regards,
Jim N
Some additional information: these errors were as expected propagated
into the Word documents. Another possible more serious error: field 604
(NoLegSecurityAltID)is listed as of type String in volume 6, similarly
in the Fields.xml file. But in volume 1, and in MsgContents.xml, this
field appears to be a repeating group count field, and thus should be of
type int. This field is (in vol 6) described as " Multileg instrument’s
individual security’s NoSecurityAltID", and refers to field 454
(NoSecurityAltID), which is in fact correctly identified as an integral
repeat count field. Ideally, since I’m writing programs which run off
these XML files, I would like to have the cleaned up. I am willing to
provide help with this. Thanks!
Just an update on your assertion - prior to FIX.4.4 there we no XML files - only word documents. The errors propogated from Word document to the XML files. Rapid Addition - wrote the programs to extract and donated the resulting XML files to FPL shortly after FIX.4.4 was published.
We will set about getting these things corrected.
Roderick,
Thank you for reporting the issues - now that FIX.5.0SP2 we have started
a repository maintenance project entitled “Repository Maintenenance
Release 2009”. We are in the process of correct errors across several
versions - we will address your issues as well.Thanks for reporting the issues.
Best Regards, Jim N
Some additional information: these errors were as expected propagated
into the Word documents. Another possible more serious error: field
604 (NoLegSecurityAltID)is listed as of type String in volume 6,
similarly in the Fields.xml file. But in volume 1, and in
MsgContents.xml, this field appears to be a repeating group count
field, and thus should be of type int. This field is (in vol 6)
described as " Multileg instrument’s individual security’s
NoSecurityAltID", and refers to field 454 (NoSecurityAltID), which is
in fact correctly identified as an integral repeat count field.
Ideally, since I’m writing programs which run off these XML files, I
would like to have the cleaned up. I am willing to provide help with
this. Thanks!
Thanks for rapid response. I’ll report other errors as I see them. The XML formats are not ideal, but I realize they were extracted from formats not meant for computer parsing. Since my programs do in fact parse the files, they catch many errors (the 454 error was caught by a consistency check that the field prior to a repeating-group’s start must be integral, for example, and the misspelled type names were caught by my program’s having a list of all legal type names).
Some suggestions: within the bundle of XML files representing a FIX dialect, there does not appear to be anything specifically identifying the proper BeginString (except by parsing the directory name, which seems crude). Why not include in Enums.xml an enum for BeginString with the only choice being the correct value (e.g, “FIX.4.3”)?
I haven’t started work on 5.0 yet, but I do notice the additional Datatypes.xml file. Such a file would be useful in the prior versions as well. I could make this file if you like. Right now my software has “burned-in” to it the names of the types. (this is how I caught “Stirng” etc.)
Thanks, Rod Llewellyn