Data Types
Phil Pritchard / Securities Industry Automation Corp.
29 Dec 1999 4:18PM ETchar and String types should specify what is meant by "any character". Does this mean any 8 bit value except the delimiter, any ASCII character (i.e., excluding values above "DEL"), or any printable ASCII character, or something else? int, float, and their derivatives are fully specified in this respect. Are non-ASCII, wide, or Unicode characters supported? Does the current usage of FIX already prohibit making such a specification?
There is also a problem with the definition of String. If MultipleFieldString is defined as a string with space-delimited values, then a String cannot contain spaces or the difference between the types would be unclear. The term "values" in the MultipleFieldString definition is also undefined. Is the intention to allow a "string" of any other type (or of several types)? This was not my first impression and a careful reading of the definition indicates that a string of Stings is what is wanted. If this is correct, a MultipleFieldString can be a string of Strings, and if String allows a space as a valid character, there is no way you can tell where one string begins and ends... On the other hand, if a String does NOT allow spaces, fields like Text are really undefinable in terms of what you want them to be.
Do we want to define multiple field types for the non-String types as we have done for Strings with MultipleFieldString? This is a parser issue since any type can be expressed as a String, but Strings are specifically free-form, not subject to validation. If you want a series of other types, as it stands now, you can't have them validated because they must be expressed not as real types but as a string of Strings (i.e., MultipleFieldString).
In all time fields including dates, the range of valid year values should start with "0001", not "0000". As we know from the controversy over when the new millennium begins, there is a problem in the fact that years start at 1 instead of 0. Has anyone been using "year zero" to express something (like the new spec uses MsgSeqNum 0 to express infinity)? Hopefully not and we can get rid of year zero as a valid year. If not, we should define what it means.
In the time fields, the required characters should be expanded to say "(and dot [or decimal point; I don't know how you want to express this] if milliseconds are supplied)".
To be complete, should a "LocalMktTimestamp" type be specified? A "LocalMktTimeOnly"?
Finally, I think we should add a Boolean type to make a standard way of implementing a 0/1, true/false, yes/no, on/off value. This will simplify parser validation. Given current practices in fields of this type in the spec, "Y"/"N" would be the valid values.
