Code names starting with lowercase character

[jvirtanen]

In OrchestraFIXLatest.xml, there is currently a handful of fields that have code names starting with a lowercase character, as opposed to all the rest of the code names (for these and all other fields) starting with an uppercase character. These codes are as follows:

• PaymentMethod(492)
  • 20 (euroSIC)
• UnitOfMeasure(996)
  • GJ (gigajoules)
  • thm (therms)
  • kL (kiloliters)
  • L (liters)
• EntitlementAttribDatatype(1779)
  • 1 (int)
  • 6 (float)
  • 12 (char)
  • 23 (data)

PaymentMethod(492) looks to be intentional as it matches the name of the service. UnitOfMeasure(996) appears less clear, as for example the code names for all other units with a "kilo-" prefix start with an uppercase character. EntitlementAttribDatatype(1779) seems intentional as well, but notably the names "int", "float", and "char" can clash with the types int, float, and char in many programming languages.

Is it intentional that all of the code names above start with a lowercase character?

Edit. Corrected UnitOfMeasure(992) to UnitOfMeasure(996) based on @kleihan's observation.

[kleihan]

@jvirtanen thank you for raising the question. I do not think that the case was chosen intentionally in all cases. However, it should not be an issue for FIX implementations. I assume you are referring to the "symbolic names" shown in square brackets in FIXimate. The names of the valid values can have such as ".", "(", and other special characters which would not be used as names in programming languages.

The names for variables should concatenate the symbolic name with other elements to avoid clashes, e.g. 1779_int. Many values are identical across fields, e.g. "New", "Add".

Small correction UnitOfMeasure is tag 996, not 992.

[jvirtanen]

Yes, I'm referring to the symbolic names (which match the name attribute of a fixr:code element in FIX Orchestra, hence the "code name" term I chose above).

I agree that the symbolic names shouldn't cause problems in practice. In my use case in Java, I define a final field for each value, using the symbolic name as the variable name. An example:

/**
 * Values for TimeInForce(59).
 */
public static class TimeInForceValues {

    public static final char Day               = '0';
    public static final char GoodTillCancel    = '1';
    public static final char AtTheOpening      = '2';
    public static final char ImmediateOrCancel = '3';
    public static final char FillOrKill        = '4';
    public static final char GoodTillCrossing  = '5';
    public static final char GoodTillDate      = '6';

}

For EntitlementAttribDatatype(1779), I currently have a special case in place to replace the symbolic names "int", "float", and "char" with "Int", "Float", and "Char" as int, float, and char would not be acceptable variable names. However, I'm also thinking if it would make more sense to just capitalize the symbolic names for all values, affecting also the other symbolic names starting with a lowercase character in the initial issue comment above.

[kleihan]

@jvirtanen thanks for the additional information. Changing symbolic names after they have been published may cause existing applications to break, i.e. I am reluctant to go down that path to remove this obstacle for the current cases. We will make sure that we do not get additional cases going forward. However, I will bring this issue to the attention of the FIX GTC for discussion.

Could you add "_" as a suffix in general to avoid the problem? That would remove the need for a special handling of EntitlementAttribDatatype(1779).

Another question: are you declaring all of these variable as public in order to use them elsewhere? How do you handle/avoid symbolic names that are not unique across FIX fields? If you generate all of these classes, you will have such cases.

[jvirtanen]

@kleihan I understand. To keep things as close to the specification as possible, I decided to keep the aforementioned special case ("char" to "Char" etc.) for the symbolic names in EntitlementAttribDatatype(1779) that clash with Java keywords and avoid altering any other symbolic names that start with a lowercase character.

In Philadelphia, these variables are declared as public so that applications using the library can refer to them. They are scoped within Java inner classes to avoid name clashes between symbolic names for different fields. For FIX 4.2, the fully qualified Java name for the value Side(59) = 1 (Good Till Cancel) is as follows:

com.paritytrading.philadelphia.fix42.FIX42Enumerations.SideValues.GoodTillCancel

With static imports in place, application code referring to this value typically looks like this:

message.addField(TimeInForce).setChar(TimeInForceValues.GoodTillCancel);