Imported from previous forum
[ original email was from Witold Sames - witold@javtech.com ]
Say somebody wishes to send an order using the XmlData and XmlDataLen tags in a FIX 4.2 message structure. The data pertaining to the order is specified in XmlData, in XML format.
Lets also assume the sending FIX engine is able to send an order message disregarding all required fields in favor of XmlData. When a FIX engine receives such a message, it will naturally reject it, because it missed required tags.
The question was raised to me what message type to use when piggy-backing XML on top of a "regular" FIX message.
Has anyone looked into this? Is this type of FIXML transport in use anywhere?
Thank you.
A good way to solve this problem is to parse the XML first before attempting to validate any of the message body tags. Much of the value of using an XML parser is in the fact that it can handle the validation for you based on the message DTD. In our implementation, if we identify that a message contains the XmlData and XmlDataLen tags, we only validate header fields, and then let the parser do the rest.
> Say somebody wishes to send an order using the XmlData and XmlDataLen tags in a FIX 4.2 message structure. The data pertaining to the order is specified in XmlData, in XML format.
>
> Lets also assume the sending FIX engine is able to send an order message disregarding all required fields in favor of XmlData. When a FIX engine receives such a message, it will naturally reject it, because it missed required tags.
>
> The question was raised to me what message type to use when piggy-backing XML on top of a "regular" FIX message.
>
> Has anyone looked into this? Is this type of FIXML transport in use anywhere?
>
> Thank you.
>
My opinion is that we should have defined a MsgType value for "XML Document" which would be sufficiently generic and obvious that one should look into the XML Document within XmlData for the "type". This provides the flexibility to easily send non-FIX XML documents via the FIX session transport.
That was not done in FIX 4.2 but is a proposed change for FIX 4.3. In the meantime, you may want to consider using a user-defined MsgType value to represent this or as suggested below get in the habit of peeking inside the XmlData if XmlData is specified vs. focusing on MsgType.
> A good way to solve this problem is to parse the XML first before attempting to validate any of the message body tags. Much of the value of using an XML parser is in the fact that it can handle the validation for you based on the message DTD. In our implementation, if we identify that a message contains the XmlData and XmlDataLen tags, we only validate header fields, and then let the parser do the rest.
>
> > Say somebody wishes to send an order using the XmlData and XmlDataLen tags in a FIX 4.2 message structure. The data pertaining to the order is specified in XmlData, in XML format.
> >
> > Lets also assume the sending FIX engine is able to send an order message disregarding all required fields in favor of XmlData. When a FIX engine receives such a message, it will naturally reject it, because it missed required tags.
> >
> > The question was raised to me what message type to use when piggy-backing XML on top of a "regular" FIX message.
> >
> > Has anyone looked into this? Is this type of FIXML transport in use anywhere?
> >
> > Thank you.
> >
>
Hi all,
We are planning to implement Fixml as a genralised std for transporting order info over network, as soon as fix engine receives, as suggested by frnd from Sillicon summit, we planned to parse before attempting to validate,
the problem is how much time it will take to carry out all these steps??How it will effect real time data transfer(Even if we used leased line)??Fixml takes more bandwidht than fix, so is it suggested for real time transfer???
Arkay
th
> A good way to solve this problem is to parse the XML first before attempting to validate any of the message body tags. Much of the value of using an XML parser is in the fact that it can handle the validation for you based on the message DTD. In our implementation, if we identify that a message contains the XmlData and XmlDataLen tags, we only validate header fields, and then let the parser do the rest.
>
> > Say somebody wishes to send an order using the XmlData and XmlDataLen tags in a FIX 4.2 message structure. The data pertaining to the order is specified in XmlData, in XML format.
> >
> > Lets also assume the sending FIX engine is able to send an order message disregarding all required fields in favor of XmlData. When a FIX engine receives such a message, it will naturally reject it, because it missed required tags.
> >
> > The question was raised to me what message type to use when piggy-backing XML on top of a "regular" FIX message.
> >
> > Has anyone looked into this? Is this type of FIXML transport in use anywhere?
> >
> > Thank you.
> >
>
[ original email was from Matt Koehler - matt.koehler@transacttools.net ]
> When a FIX engine receives such a message, it will naturally reject it, because it missed required tags.
I would hope that a FIX engine purporting to support FIXML would be smart enough to understand that when XMLData is populated, the standard tag-value fields no longer take immediate precedence.
It should understand that header information includes important identification, sequencing, and possibly encryption information; the rest of the content can be structured as XML and embedded in the two fields created for that
purpose. Hope this is helpful!