Imported from previous forum
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
Is it acceptable to place non-FIXML XML messages within the FIX Session Layer?
Specifically, for advanced trading applications, there may be some specific information on configuring a trading session for a user (user profile information for instance), specifying risk management or trading limit information that is not currently covered by the FIX Specification.
One approach would be to define SOAP objects (XML DTD for describing an object) for these advanced (and possibly optional features) that would essentially tunnel through the FIX session. By keeping these SOAP objects only for optional information, users not able or willing to build up the XML messages or to parse XML messages could simply ignore them.
An auxiliary question that has to be asked is - how many off the shelf FIX engines can handle an embedded XML string in their FIX 4.2 implementations (not parsing - just tunneling)?
It is certainly possible to send non-FIXML payloads via the FIX session. We intentionlly designed it this way (e.g. we renamed the tags XmlData and XmlDataLen vs. FixmlData and FixmlDataLen). The idea is that there is often a need to transmit XML data and one approach is to send it via the FIX session-layer. While the FIX session-layer may not be perfect, it has stood the test of recent time and provides a real-time communications mechanism using Internet networking standards with message gap detection and recovery. The FIX Technical Committee has encouraged several "sister" protocols (FpML, GSTPA, etc) to consider transmitting their XML messages via FIX session layer without precluding the ability to use other mechanisms (e.g. http POST).
Of course your counterparty must be able to handle the "payload" or content you send and you are no longer sending "FIX" messages.
Regarding your specific suggestion, it sounds like you want to send a “normal” (base) message with an XML block of “abnormal” (supplemental) information. The question to ask is if you were to send the base information in XML (e.g. FIXML), would the supplemental information also be conveyed within the same XML “document” or would it be auxiliary information to it? If the latter, I would recommend considering a user defined tag for the supplemental XML data and it’s corresponding length. My argument is don’t send the base message in tag=value and the supplemental information in the XmlData block unless you would be able to combine both the base and supplemental information into a single XmlData block sometime in the future. It might be possible for FIXML itself to define a field/structure within it to represent the supplemental information.
> Is it acceptable to place non-FIXML XML messages within the FIX Session Layer?
> Specifically, for advanced trading applications, there may be some specific information on configuring a trading session for a user (user profile information for instance), specifying risk management or trading limit information that is not currently covered by the FIX Specification.
> One approach would be to define SOAP objects (XML DTD for describing an object) for these advanced (and possibly optional features) that would essentially tunnel through the FIX session. By keeping these SOAP objects only for optional information, users not able or willing to build up the XML messages or to parse XML messages could simply ignore them.
> An auxiliary question that has to be asked is - how many off the shelf FIX engines can handle an embedded XML string in their FIX 4.2 implementations (not parsing - just tunneling)?
>
>