Imported from previous forum
Let’s say I have a FIX message ‘A’ and if field 33 is present and set in the message then field 103 must also be set (‘A’, 33 and 103 are all random examples, not meant to refer to their actual respective FIX messages and fields). In this case for SBE should I specify two message schemas, one in which 33 and 103 are present and required and one in which neither are specified? It seems like this would be the prefered method to avoid having to do runtime conditional parsing.
It’s hard to judge the best design without more context, but in an SBE message schema, it is easy to create multiple templates for the same FIX MsgType that are optimized for specific scenarios. This is a design-time analysis rather than run-time. But it doesn’t mean that you can necessarily eliminate all conditionally required fields.
In the past, conditionally required fields have always required an interpretation of text in the FIX specs. The FIX Orchestra Working Group is planning to develop a machine-readable and executable expression of the condition, something like StopPx is required when “OrdType IN [‘Stop’, ‘StopLimit’]”. Whether you choose to execute the expression at run-time will be your decision, but at least such a grammar reduces ambiguity.
Thanks Donald for the quick response!