According to FIX specification there are only two FIX components of OptimisedImplicitBlockRepeating type:
However, this type doesn’t seem to be documented anywhere. What’s the difference between OptimisedImplicitBlockRepeating and normal ImplicitBlockRepeating?
It is a nightmare of my own making. An optimization too far. When we developed the attribute based, message size optimized version of FIXML back in 2004, We had a situation where we had a component nesting where the InstrmtLegGrp had a single member, which was another component the InstrumentLeg component resulting in an XML construct of <Leg><Leg ....></Leg></Leg> We over-optimized this to eliminate the component nesting, so that the fields in InstrumentLeg would be included into the parent to create <Leg ..../>, where … is the set of fields represented as XML attributes to the component, which is represented as an XML element.
Unless you need to write a FIXML generator, you can effectively ignore the “Optimised” prefix.
We have deprecated this unfortunate over-optimization, replacing it with the notion of an inline component, where components marked as inline will have their fields included in the parent. Again, this only applies to FIXML at this time or other such encodings that may choose to take advantage of this capability.
This concept will be removed from FIX Orchestra, which is the future version of the FIX Repository.
And, as I am winding down this career, my apologies to the FIX Community for coming up with this daft concept in the first place for FIXML.
See also EP 105 Appendix D on Inline Component Reference Enhancement to the FIXML Standard. Don’t be confused that EP 105 (https://www.fixtrading.org/packages/ep105/) is actually about Parties Reference Data.
@jim.northey I’m actually implementing FIX to FIXML converter, so this information is crucial for me. Thank you for the great response!