Imported from previous forum
One of the nice things about Fast is that be rearranging the order of fields in a message you can increase compression. By putting optional and rarely used fields at the end of a message, the PMAP can be truncated.
Within repeating groups the reordering of fields can not be easily done, because the order is fixed by the specification. This is a real pain in the neck. To optimize the output for Fast you have to change the specification, communicate the change to the customer, and recode the parsers.
Why not introduce a delimiter field (lets say id XXX) that supports start group and end group characters? Then you could have something like:
NOXXX=3 XXX={ … XXX=} XXX={ … XXX=} XXX={ … XXX=} …
The ‘XXX={’ and ‘XXX=}’ are the start and end tokens. The same idea is used in Lisp, XML, and many computer languages.
You could then relax the restriction on the ordering of fields within a repeating group by stating that within the delimiters the fields are unordered.
In Fast, the delimiters could be defined as constants and would occur no overhead. Fast templates could optimize the order of fields within groups without causing a changed to the specification.
In Fix, general parsers could be written without needing to know the context of a message; a parser doesn’t need to know the set of fields that a group is meant to contain. This would make parsers much more robust. It would allow user defined fields to be easily added to a repeating group.
This change could be used for new messages and groups and retrofitted as necessary to existing messages.
Variations on this would be to allow other delimiter characters with set or list semantics.
Regards,
Christopher Helck
[ original email was from Joseph Horowitz - jhorowitz@aegisoft.com ]
> In Fix, general parsers could be written without needing to know the
context of a message
Same suggestion made back in 2005, and prior,
see: http://fixprotocol.org/discuss/read/c350a885