[This message was posted by Mahesh Kumaraguru of <[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/a3b72ea8 - PLEASE DO NOT REPLY BY MAIL.]
I agree FIX is not free from ambiguities, but we should try to disambiguate as many ambiguities as possible. > Asking the sender was obviously not meant for a message received in real- > time during production, it is meant for the process of agreeing on rules > of engagement during a design or testing process. > > If IOC+AON were the same as FOK, why support two ways to express this? > FOK is simpler as it only needs a single field. FIX is not free from > ambiguities, why introduce new ones? > > > Hanno, > > > > I think there is a Gap. > > > > IOC is a Time descriptor and AON is a Execution Quantity descriptor > > and I see these as two different dimensions ( > > http://en.wikipedia.org/wiki/Dimensional_analysis ). For example I see > > Price and Quantity as two independent dimensions in FIX. > > > > Effectinely TimeInForce = IOC + ExecInstruction = AON becomes > > TimeInForce 59 = 4 FillOrKill (though this not written anywhere in the > > FIX Specs). > > > > Asking the sender may not be an option in high freqency Algorithmic > > trading systems where automated Algorithims have placed this trade (a > > voice Robot may answer the call :-( > > > > Different values in ExecInst 18 belong to different dimensions. Since > > this field can contain multiple instructions separated by space, > > values from different dimensions may coexist under the mutually > > exclusive rule within the same dimension, but I believe some should be > > seperated into new FIXTags or removed from 18 and merged into existing > > FIXTags. For example, values of 18 > > > > A (No cross) and B (OK to cross) describe whether a Cross is permitted > > > > D (Percent of volume), E (Do not increase), F (Do not reduce), G (All > > or none) describe behaviour of the Quantity dimension > > > > J (Reinstate on Trading Halt), K (Cancel on Trading Halt), m (Suspend > > on Trading Halt) describe what to do in the event of Trading halt. > > > > H (Reinstate on system failure), Q (Cancel on system failure) and l > > (Suspend on system failure) describe what to do in the event of > > System failure > > > > L (Last peg), M (Mid-price peg), O (Opening peg), P (Market peg), R > > (Primary peg), W (Peg to VWAP), d (Peg to Limit Price) decsribe the > > Price Peg type. > > > > g (External Routing Allowed) and h (External Routing Not Allowed) > > describe External Routing permission. > > > > S (Suspend) and q (Release from suspension) describe the Suspend / > > Unsuspend behavior. > > > > (The above values are not a complete list but indicative of the Gap I > > am analysing) > > > > Since ExecInst 18 is used different MessageTypes, we could do a Gap > > analysis to see how the different values can be refactored for new > > FIX.Version or Service pack. But for the sake of older versions, we > > should try to document a matrix of ExecInst values for different > > message types and the expected behaviour when some other field like > > TimeInForce contains a specific value. > > [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 -~----------~----~----~----~------~----~------~--~---
