[This message was posted by Dave Law of Susquehanna <[email protected]> to the
"4.4 Changes" discussion forum at http://fixprotocol.org/discuss/17. You can
reply to it on-line at http://fixprotocol.org/discuss/read/4d694293 - PLEASE DO
NOT REPLY BY MAIL.]
> Jay,
>
> Could you point me to the FIX documentation which stated "header and
> body tags should not be intermixed."
>
> I have written a FIX broker simulator in Java which tests three
> different Buy side systems (two of them in FIX.4.2 and one in FIX.4.0)
> and none of them reject messages with intermixed header and body tags as
> incorrect.
>
> John,
>
> Since FIX.4.0 "The general format of a FIX message is a standard header
> followed by the message body fields and terminated with a standard
> trailer. Each message is constructed of a stream of <tag>=<value>
> fields. Except where noted, fields within a message can be defined in
> any sequence (i.e. relative position of a field within a record is
> inconsequential); exceptions are explicitly defined otherwise (certain
> header fields and fields within repeating data groups)."
>
> So FIX.4.4 introduced no new Field ordering requirements compared to
> FIX.4.0. Upto FIX.4.4 for 8, 9 and 35, there is explicit mention as
> first, second and third fields of "every" FIX message, but there is no
> such mention for any other fields.
>
> Regards,
> K. Mahesh
I don't think there's an explicit mention that the tags shouldn't be mixed, but
you can derive it from these three points:
1. Standard header definition fields (for example, FIX 4.2 with Errata
20010501, pp 22-23)
2. The quote you gave to John above ("The general format of a FIX message is a
standard header followed by the message body fields and terminated with a
standard trailer").
3. A field is either a header field or a body field. I don't have a reference
for this - you can either find the reference or check each message type in the
spec ;-)
Thus if I was writing a really pedantic fix engine, I could impose the
following ordering:
8, 9, 35, {other header fields - CompIDs, etc}
{body fields}
{trailer fields}
So whilst there is no requirement to order the remaining header fields after
tag 35, the first one that I encounter that is a non-header field implies that
the header has been completely read. Any subsequent header fields will cause me
to reject the message.
As mentioned previously, the most sensible approach seems to be to adhere to
the above when sending messages and allow non-conformance on receiving messages
(repeating groups notwithstanding).
[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
-~----------~----~----~----~------~----~------~--~---
