[This message was posted by Jay De Young of Chicago Mercantile Exchange <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/8cbd7125 - PLEASE DO NOT REPLY BY MAIL.]
I had suggested this to Matt quite some time ago. I believe there are a "handful" of tags that are structurally conditionally required, one of which you indicate regarding repeating groups. A couple of others relate to the Execution report (as mentioned below)which has several purposes. The general purpose specification would be not be the best place for other "conditionally required" tags that are subject to the rules of engagement. This could get quite tedious and lengthy (and subject to change). Perhaps any field indicated as "not required" (on "inbound" messages anyways) should ALWAYS be investigated according to the rules of engagement. > Mahesh, > > I agree that there is benefit in doing this but this would be a major > undertaking for FPL and is a task that is far from trivial. There are > many reasons for a conditional requirement and these would still have to > be described in the comment column. > > A special (and trivial) case of a conditional requirement are the > repeating groups where the first field is always required when using the > tag=value syntax and other fields are required for every instance of a > repeating group (Conditionally required when NoXXX>0). > > Less trivial are conditional requirements that FPL cannot pre-define but > that are still needed in the rules of engagement. For example, the > ExecutionReport has an optional InstrmtLegExecGrp which becomes > conditionally required when you convey a multi-leg execution on the leg > level and not on an instrument level. What I am trying to say is that a > large number of fields are conditionally required for semantic reasons > that may or may not be relevant for any given implementation. This > should be left for the Rules of Engagement to describe. > > It might make sense and be a reasonable effort to automatically flag > message fields in the Req'd column that have the term "conditionally > required" in their comment column. This would give a heads up to > developers that they really need to read the comment column :-). > > Regards, Hanno. > > > Hanno, > > > > In FIXimate / FIX specifications, presently the required column just > > says yes or no. I think this should be changed to have the words > > > > Reqd - The field has to be present in the message - there are no ifs > > and buts > > > > Cond - The field is conditionally required based on presence or > > absence of other fields or values in other fields > > > > Opt - The field is optional > > > > I have come accross many people interpreting the Required = N without > > looking at the comments column. Having value Cond would make these > > folks look further towards conditions in which the field is required. > > > > Regards, Mahesh > > > > > I think this needs to be clarified to avoid confusion. The column > > > "Req'd" in the spec is not the only way for FIX to declare a field > > > to be required or not. The comment column is another possible > > > source. The position of a field in a repeating group is a third > > > possible source when using the tag=value syntax. The previous poster > > > actually quoted from the comment in the spec. > > > > > > What happens if you do not send tag 11 in the Execution Report > > > responding to a New Order Single? The submitter of the order will > > > have a hard time to know which report refers to which order entry > > > message if he does not wait for a response before sending another > > > new order. From then on he could use the exchange order ID (tag 37) > > > but it is neither permitted nor recommended to omit tag 11 in the > > > Execution Report in the plain vanilla cases. There are very few > > > exceptions where tag 11 is not available and thus cannot be > > > returned. > > > > > > What advantage does it have to suppress tag 11 on an > > > ExecutionReport? I would like to understand why that makes life > > > easier for the recipient of order messages, regardless of what the > > > spec says. > > > > > > Thank you, Hanno. > > > > > > > According to the FIX protocol spec, tag 11 is not required in the > > > > execution reports, yes almost all firms send this tag in the > > > > execution reports but it is not a required tag, it is only > > > > required in the New Order messsges. > > > > > > > > > Tag 11 ClOrdID is required in all execution reports which are > > > > > sent in response to electronically submitted orders. > > > > > > > > > > Tag 41 OrigClOrdID is required when Tag 150 ExecType is > > > > > PendingCancel > > > > > (6), Replaced (5) or Canceled (4), for other ExecTypes, sending > > > > > Tag 41 is meaningless as many FIX engines would not be > > > > > looking for it in ExecReports. > > > > > > > > > > > > > > > > > When you say execution report do you mean the response to the > > > > > > Cancel/Replace message(i.e Pending or Replaced msg)? If so, > > > > > > then tag 41 is required and tag 11 can be sent but is not > > > > > > required. If you mean sending executions (fills) on a modified > > > > > > order, then tag 41 and 11 can be sent, it is not against the > > > > > > FIX protocol, but they are not required. [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
