Specifying Byte Vector Default Values in FAST Templates

, ,
1

Imported from previous forum

2

When specifying a default value for a byteVector field’s operator in the FAST templates there seems to be no standard way of doing this.

An example production FAST installation uses the following byteVector field definition.

Knowing FIX, it is obvious that the default value is ASCII-encoded. The issue with using ASCII-encoded default values for byteVector fields is that not all byteVector values can be represented by ASCII encoding.

In OpenFAST we made the assumption that the byteVector default value would be hex-encoded. The following is how OpenFAST expects the same field defined.

Is there a standard encoding for byteVector default values? If not, can I propose we use the hex encoding? It might make sense to use a 0x prefix so that it is clear to consumers of the templates that the byteVector default value is hex-encoded.

Thanks,
Jake

3

Hi,

This is covered in section 8.1.3 (and 8.4) in the FAST specification:

“The string is interpreted as an even number of hexadecimal digits [0-9A-Fa-f] possibly interleaved with whitespace. The literal is turned into a byte vector by first stripping any whitespace. Then each pair of characters is interpreted as a hexadecimal number representing a single byte.”

(This means that isn’t strictly legal, but would be)

/David

When specifying a default value for a byteVector field’s operator in the FAST templates there seems to be no standard way of doing this.

An example production FAST installation uses the following byteVector field definition.

Knowing FIX, it is obvious that the default value is ASCII-encoded. The issue with using ASCII-encoded default values for byteVector fields is that not all byteVector values can be represented by ASCII encoding.

In OpenFAST we made the assumption that the byteVector default value would be hex-encoded. The following is how OpenFAST expects the same field defined.

Is there a standard encoding for byteVector default values? If not, can I propose we use the hex encoding? It might make sense to use a 0x prefix so that it is clear to consumers of the templates that the byteVector default value is hex-encoded.

Thanks,
Jake

4

Great, thanks for pointing that out. I was looking in the FAST specification for where this might be defined, but mainly read through section 6. So it looks like OpenFAST is following the spec. I must have read that section a long time ago and just forgot about it.

Thanks,
Jake

Hi,

This is covered in section 8.1.3 (and 8.4) in the FAST specification:

“The string is interpreted as an even number of hexadecimal digits [0-9A-Fa-f] possibly interleaved with whitespace. The literal is turned into a byte vector by first stripping any whitespace. Then each pair of characters is interpreted as a hexadecimal number representing a single byte.”

(This means that isn’t strictly legal, but would be)

/David

When specifying a default value for a byteVector field’s operator in the FAST templates there seems to be no standard way of doing this.

An example production FAST installation uses the following byteVector field definition.

Knowing FIX, it is obvious that the default value is ASCII-encoded. The issue with using ASCII-encoded default values for byteVector fields is that not all byteVector values can be represented by ASCII encoding.

In OpenFAST we made the assumption that the byteVector default value would be hex-encoded. The following is how OpenFAST expects the same field defined.

Is there a standard encoding for byteVector default values? If not, can I propose we use the hex encoding? It might make sense to use a 0x prefix so that it is clear to consumers of the templates that the byteVector default value is hex-encoded.

Thanks,
Jake