[This message was posted by Hanno Klein of Deutsche Börse Systems <[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/43caca54 - PLEASE DO NOT REPLY BY MAIL.]
You would then give up the distinction between "non-standard" and "invalid" which I believe is of value to have. The documentation, e.g. FIXimate, and the development repository (e.g. for code generation) can and should be reduced to the subset of used messages, fields and enum values but not the repository running in production in the FIX engine. This guarantees that rejections of unsupported elements occur on the application/business level and functional experts deal with the issues. > I would say that option 3 is the way to go. Be careful thought that the > custom FIX repository is supposed to be a true reflection of your own > FIX spec -- so you only exclude the fields that are not supported in > your spec. In other words, no "creativity" is allowed in the repository > itself, and any change should start with your spec. > > Just my two cents... > > > Hi, > > > > I can think of the following ways of handling unsupported > > optional fields: > > > > 1) Silently ignore the field. > > 2) Send a business level reject, for example an ExecutionReport to > > reject a New Order Single, indicating that the field is not > > supported. 3) Exclude the non supported field in our FIX repository > > which will have the effect that we send a session level reject > > instead with 373=3 (undefined tag) as we do not recognize that tag. > > > > Please advise > > > > Regards, Bernt [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.
