Imported from previous forum
[ original email was from John Prewett - jprewett@lavatrading.com ]
In the protocol specification, fields in a message are listed with an attribute having a value of either "required" or "not required".
This doesn’t elegantly lend itself to dealing with conditionally required fields such as LastShares(32) and LastPx(31) on an ExecutionReport.
With FIX.4.0 & FIX.4.1, these fields were specified as "required" and the comment indicated that they were not required in the case of ExecTransType=cancel. This changed with FIX.4.2 and the fields were specified as "not required" with the comment hinting that they are required under certain circumstances.
So I assumed that there had been a clean-up and that a field that was conditionally required was now given the attribute of “not required” as it wasn’t required in every circumstance.
You can imagine my horror 
when I recently looked at the Allocation message for the first time and discovered that there are conditionally required fields that have a value of "required*" or "required**" ! The comments associated with the fields NoOrders(73), ClOrdID(11), NoAllocs(78), AllocAccount(79) and AllocQty(80) indicate the circumstance(s) under which these fields are not actually required.
I thought the clean-up in FIX.4.2 was a good thing from a FIX engine developer’s perspective in the fact that conditionally required fields were listed as “not required”. Now I discover the Allocation message breaks my assumptions.
I think it would be a good idea if conditionally required fields were represented consistently in all messages.
Possible choices:
- Ignore this request and focus on more important stuff.
- Make all conditionally required fields appear as "not required".
- Enhance the attribute to have three values: "required", "not required" and "conditionally required".
Slightly late, but "Happy New Year" anyway.
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
Thanks John for the suggestion. In my own spec writing I like to use three values - Optional, Mandatory and Conditional. I hope we can incorporate this into the 4.4 spec that the Tech Committee is working on this winter.
- Dean Kauffman
> In the protocol specification, fields in a message are listed with an attribute having a value of either “required” or “not required”.
>
> This doesn’t elegantly lend itself to dealing with conditionally required fields such as LastShares(32) and LastPx(31) on an ExecutionReport.
>
> With FIX.4.0 & FIX.4.1, these fields were specified as “required” and the comment indicated that they were not required in the case of ExecTransType=cancel. This changed with FIX.4.2 and the fields were specified as “not required” with the comment hinting that they are required under certain circumstances.
>
> So I assumed that there had been a clean-up and that a field that was conditionally required was now given the attribute of “not required” as it wasn’t required in every circumstance.
>
> You can imagine my horror when I recently looked at the Allocation message for the first time and discovered that there are conditionally required fields that have a value of “required*” or “required**” ! The comments associated with the fields NoOrders(73), ClOrdID(11), NoAllocs(78), AllocAccount(79) and AllocQty(80) indicate the circumstance(s) under which these fields are not actually required.
>
> I thought the clean-up in FIX.4.2 was a good thing from a FIX engine developer’s perspective in the fact that conditionally required fields were listed as “not required”. Now I discover the Allocation message breaks my assumptions.
>
> I think it would be a good idea if conditionally required fields were represented consistently in all messages.
>
> Possible choices:
> 1. Ignore this request and focus on more important stuff.
> 2. Make all conditionally required fields appear as “not required”.
> 3. Enhance the attribute to have three values: “required”, “not required” and “conditionally required”.
>
> Slightly late, but “Happy New Year” anyway.
>