re: Data Types
Scott Atwell / American Century <>
29 Dec 1999 4:52PM ET> char 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?
>
-- Non-ASCII, Unicode characters, etc. are supported in 4.2 via the new "Encoded" fields. These also support Japanese character sets.
char and String are currently defined as "any alphanumeric character or punctuation" and the description of "Data Types" indicate that they are to be mapped to ASCII strings. This should exclude the data type of "data", though as it's non-ASCII. We could consider documenting them as representing "any printable ASCII character" or as "an ASCII character with decimal representation between 20-128". Thoughts?
> 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.
>
-- String allows spaces. "MultipleFieldString" is a special implementation of a String. It has been renamed "MultipleValueString" for the next draft. It is a String representation containing one or more values (these enumerated values are typically one character, could be more than one in the future, but cannot contain a space) which are delimited or separated by a single space. A particular field is either of String (free-form) data type or MulitpleFieldString or another data type but not both.
>
> 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).
-- As a general rule-of-thumb, we prefer repeating groups to MultipleValueString data types. ExecInst has been a notable exception in the past and a couple of the fields added for market data and mass quoting are of MultipleValueString data type solely because of bandwidth issues for those types of messages. One's parser should know what the data type is for a given field and parse it accordingly. Any existing parser capable of handling orders is capable of handling the MultipleFieldString as it had to be able to parse ExecInst.
>
> 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.
-- I have no opinion on this.
>
> 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)".
-- I have added to the next draft "period" as one of the "required characters" in the Data Types section for UTCTimestamp and UTCTimeOnly.
>
> To be complete, should a "LocalMktTimestamp" type be specified? A "LocalMktTimeOnly"?
-- No. We want to use UTC/GMT for timestamps. We need the ability to specify the date in a particular market thus LocalMktDate (previously named "date") has been used for that.
>
> 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.
-- Agreed and added that to the list of proposed changes for consideration for the next draft.
Thanks.
