User defined fields part of FIXimate3.0 and the repository?

, ,
1

Imported from previous forum

2

Kevin Houstoun, Rapid Addition, and GTC Co-chair raised an interesting point. Should we include the publicly identified custom fields (5000-9999) as part of the repository and FIXimate3.0? This is an interesting question that hopefully spark some public debate. At the same time as Kevin raised this issue he pointed out that there needs to be an official policy for the creation and support of custom fields. Can firms block out ranges and not publish their meaning? This doesn't seem like "publication" of common values. What happens with custom fields that are later incorporated into the FIX Specification? Should these be maintained for use with earlier versions of FIX or should we remove these values from the list of custom fields or mark them as replaced?

3

[ original email was from John Prewett - jprewett@lavatrading.com ]
I would suggest that putting custom fields into the repository has only a very small advantage and several disadvantages.

Advantage:

  1. Define the custom tags in the Fields.xml for everyone to use.

Disadvantages:

  1. No data type defined in the user field specifications. Does that make everything ‘String’?
  2. No specification of which messages these fields apply to.
  3. Problems Jim previously mentioned when they are deprecated.

Inasmuch as I am aware, most FIX engines use a dictionary of some type. These dictionaries are able to be “enhanced” with the custom tags as needed, with their full set of attributes (data types, applicability to specific messages).

I say leave well alone.

JohnP

4

I agree with John, especially regarding the current state of user-defined fields. This topic could be revisited after a cleanup.

For now, a simple download as CSV would be sufficient. The download should be applied to what is displayed to allow to save search results.

I would suggest that putting custom fields into the repository has only
a very small advantage and several disadvantages.

Advantage:

  1. Define the custom tags in the Fields.xml for everyone to use.

Disadvantages:
2. No data type defined in the user field specifications. Does that
make everything ‘String’?
3. No specification of which messages these fields apply to.
4. Problems Jim previously mentioned when they are deprecated.

Inasmuch as I am aware, most FIX engines use a dictionary of some type.
These dictionaries are able to be “enhanced” with the custom tags as
needed, with their full set of attributes (data types, applicability to
specific messages).

I say leave well alone.

JohnP

5

The user-defined fields need to be brought back to what they were intended for. Other people should have the ability to use them. Here is my list of actions that I believe should be taken, the more the better. They are listed by (my personal) priority and will hopefully lead to a lively debate. Numbers are approximate and there could be overlap in counting.

  1. Remove fields with a name containing “Reserved” (450 occurrences)
  2. Remove fields with a name containing “Algo” (90)
  3. Remove fields with a name containing “UDF” (60)
  4. Remove generic fields with a name containing “Parameter”/“Paramater” (130)
  5. Remove all names of firms from field names (Omgeo: 180, ML 30, TSX: 30, HSFX: 20, Lehman: 15, NYSE:10) to make them available to others
  6. Remove generic fields emulating repeating groups such as Time0, Time1,… and Pair 1, Pair2,… unless a clear definition is provided
  7. Remove “Cust(om)” from field names where it indicates “user-defined”
  8. Remove “FIX” from field names
  9. Put all fields without description on notice for a limited period and remove if descriptions are not made available by the firm having defined the field.
  10. Consolidate duplicate names (e.g. DisplaySize occurs 3 times)
  11. Remove fields that are now available in the standard with tag numbers below 5000
  12. Open up number range 8000-8999 and encourage extension of standard fields to cover what has been defined in this area so far.

This would make about 1000 tags available again with an additional 1000 if the range 8000-8999 can be opened.

We need a minimal process for quality assurance going forward. My view is that selected members of the GTC should be responsible for approval of user-defined tags. A small set of guidelines published by FPL would make this approval process transparent. Most of these rules can be derived from my suggested list of actions above.

Regards,
Hanno.

Kevin Houstoun, Rapid Addition, and GTC Co-chair raised an interesting
point. Should we include the publicly identified custom fields (5000-
9999) as part of the repository and FIXimate3.0?

This is an interesting question that hopefully spark some public debate.

At the same time as Kevin raised this issue he pointed out that
there needs to be an official policy for the creation and support of
custom fields.

Can firms block out ranges and not publish their meaning? This doesn’t
seem like “publication” of common values.

What happens with custom fields that are later incorporated into the FIX
Specification? Should these be maintained for use with earlier versions
of FIX or should we remove these values from the list of custom fields
or mark them as replaced?

6

My 2 cents:

  1. agree we need some type of process but it needs to be one that is manageable as firms who register custom fields tend to need them in implementations right away

  2. We need to be careful about removing fields that are already included in later versions of FIX. Case in point, there are a number of fields registered for fixed income that are used by FIX 4.2 implementations that are were included in FIX 4.4, but there are still 4.2 FI implementations out there. Some custom fields were registered also because they are tags available in later versions but not in 4.2 and the implementation wants to use 4.2 (e.g. some tags that was proposed by the AlgoWG a while back, or tags for FX that is available in 5.0 but the implementation is 4.4).

  3. I also feel that when a field is registered more required information is needed: message(s) it is to be used in, data type of the field, a clear definition, enum list if there is one. This would promote reuse and help decision makers who need to “approve” the request.

  4. In terms of Hanno’s list, I would put #1 and #8 at the top of the list to open up available tag numbers.

The user-defined fields need to be brought back to what they were
intended for. Other people should have the ability to use them. Here
is my list of actions that I believe should be taken, the more the
better. They are listed by (my personal) priority and will hopefully
lead to a lively debate. Numbers are approximate and there could be
overlap in counting.

  1. Remove fields with a name containing “Reserved” (450 occurrences)
  2. Remove fields with a name containing “Algo” (90)
  3. Remove fields with a name containing “UDF” (60)
  4. Remove generic fields with a name containing
    “Parameter”/“Paramater” (130) 5. Remove all names of firms from
    field names (Omgeo: 180, ML 30, TSX: 30, HSFX: 20, Lehman: 15,
    NYSE:10) to make them available to others
  5. Remove generic fields emulating repeating groups such as
    Time0, Time1,… and Pair 1, Pair2,… unless a clear
    definition is provided
  6. Remove “Cust(om)” from field names where it indicates “user-
    defined”
  7. Remove “FIX” from field names
  8. Put all fields without description on notice for a limited period
    and remove if descriptions are not made available by the firm having
    defined the field. 10. Consolidate duplicate names (e.g. DisplaySize
    occurs 3 times)
  9. Remove fields that are now available in the standard with tag
    numbers below 5000
  10. Open up number range 8000-8999 and encourage extension of standard
    fields to cover what has been defined in this area so far.

This would make about 1000 tags available again with an additional 1000
if the range 8000-8999 can be opened.

We need a minimal process for quality assurance going forward. My view
is that selected members of the GTC should be responsible for approval
of user-defined tags. A small set of guidelines published by FPL would
make this approval process transparent. Most of these rules can be
derived from my suggested list of actions above.

Regards, Hanno.

Kevin Houstoun, Rapid Addition, and GTC Co-chair raised an interesting
point. Should we include the publicly identified custom fields (5000-
9999) as part of the repository and FIXimate3.0?

This is an interesting question that hopefully spark some
public debate.

At the same time as Kevin raised this issue he pointed out that
there needs to be an official policy for the creation and support of
custom fields.

Can firms block out ranges and not publish their meaning? This doesn’t
seem like “publication” of common values.

What happens with custom fields that are later incorporated into the
FIX Specification? Should these be maintained for use with earlier
versions of FIX or should we remove these values from the list of
custom fields or mark them as replaced?