FAST Extension proposal - MAP INLINE

Imported from previous forum

I wanted to comment on this extension proposal, but did not see a thread so I will start one here by using the current Extension Proposals document as a starting point.

Jake

EXTENSION PROPOSAL - MAP INLINE (table of {bit value, real value} pairs)

Background

In some cases, fields with a small number of values (such as Boolean or ‘OrdType’) could be represented with fewer than 7 bits, which is the minimum wire size for a FAST field. The recent BITGROUP proposal is a mechanism to combine several fields together so they can better use these 7 bits (or 14 or 21…). Greater efficiency could be realized by ‘inlining’ these few bits into the pmap itself.

Introduction

An INLINE operator combined with a MAP will define a small number of bits to represent the actvalues being expressed. Early on in FAST, we discussed using another bit of pmap for a NULL flag, but chose to use NULL values instead for consistency. The same argument was made for Boolean values represented in pmap – consistency won out. This proposal argues that expanding pmap bit usage to include inline field values gives sufficient compression to warrant the complexity.

Examples

Assume we have the field MDUpdateAction which will use values 0, 1, and 2. This could be expressed with a simple MAP INLINE:
{ 00, “0” }
{ 01, “1” } { 10, “2” } An extension of this technique could be used for variable bit fields:
{ 0, “0” }
{ 10, “1” } { 11, “2” } Another example would by OrdType (optional in MDEntry). To support NULL values, you could express the map like this:
{ 0, NULL }
{ 10, “0” } { 11, “1” } Thus, this field takes 1 or 2 bits instead of one byte.

Wire Representation

The wire format would necessarily change. When the next field in the template uses MAP INLINE, there would be no field in the message body (after the pmap), rather, that data would be in the pmap itself. So the next bits in the pmap would be used to traverse the map.

EXTENSION PROPOSAL - Boolean Type

Background

Several fields in FIX use the datatype Boolean. Encoding these fields in FAST 1.1 requires an entire byte.

Introduction

A new boolean type in FAST could be used to represent these fields as a single bit in the presence map. The use of booleans in FAST has been brought up several times before and should be reconsidered as an alternative to the MAP INLINE proposal. The boolean type cannot represent boolean fields that are sometimes null. This may be problematic for FIX over FAST implemenations as a Boolean field could be set to ‘Y’, ‘N’ or not present at all. Since only a single presence map bit is used, field operators are unnecessary.

Examples

Wire Representation

A single presence map entry would indicate the value of the boolean field.

[ original email was from Mikael Brännström - m.brannstrom@ngm.se ]
> EXTENSION PROPOSAL - Boolean Type

A single presence map entry would indicate the value of the
boolean field.

This can actually be modelled with FAST 1.1 using the constant field operator for an optional field. I.e. a field can have the value ‘Y’ or be absent (which means ‘N’).

This works well for the FIX fields PossDupFlag and PossResend where you either set the field to ‘Y’ or don’t set it at all.

Regards
Mikael