[This message was posted by Nathan Kidd of NMK Consulting Ltd <[email protected]> to the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You can reply to it on-line at http://fixprotocol.org/discuss/read/7c642e7d - PLEASE DO NOT REPLY BY MAIL.]
Many thanks for the confirmation, all looks good now! > Hi Nathan, > > There is no defined constraint on the operators defined for a "field" in > FAST1.1. FAST is all about compression and squeezing that extra bit of > business information in a network message. > > Eurex EnBS took a pragmatic approach for applying operators to fields. > Take for instance your example for "prodId". The Product Reference > Message the prodId follows the copy operator and for the Single Leg > Reference it follows copy operator. The reason being there is only one > message for product in "product reference" and many single leg > instruments per product in "single leg reference" message. This ensures > that the complexity of processing due to FAST operators is balanced by > the actual compression of the data. > > To reiterate FAST protocol leaves it to the application designer to use > the power of FAST as per the application requirements and does not put > any constraints on the field operator associations. > > Hope I am clear. > > I would support option 1 from your suggestions below. > > Regards, > > > Hi, > > > > I'm currently working on a port of our C++ decoder from CME FAST to > > Eurex EBS. There appears to be something different happening with the > > default key names for the Eurex global dictionary. > > > > Multiple EBS templates contain the same field, for example "prodId". > > However, different templates are applying different operators to this > > key - sometimes its DEFAULT, sometimes NOOP, sometimes COPY, etc, all > > for the same prodId string field. > > > > Our dictionaries aren't currently implemented to allow a change of > > operator for a key after it is initially contructed. > > > > Before I start making tweaks, I was hopeing someone could verify which > > of the following is the correct solution: > > > > 1) Allow different operators to be applied to the same key and > > previous value as retrieved from the dictionary. > > > > 2) Append the operator to my keyname, (so key becomes "prodId_copy" > > for example), and thereby each key maintains the current > > implementation where one key can only have one operator applied to it. > > > > 2) Something different :) > > > > Many thanks in advance for any advice! > > > > Cheers, Nathan [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 -~----------~----~----~----~------~----~------~--~---
