Except where noted, fields within a message can be defined in any sequence


#1

The volume 1 of specification says:

Except where noted, fields within a message can be defined in any sequence (Relative position of
a field within a message is inconsequential.) The exceptions to this rule are:

And the Item 4 says:

Fields within repeating data groups must be specified in the order that the fields are
specified in the message definition within the FIX specification document. The NoXXX field
where XXX is the field being counted specifies the number of repeating group instances that
must immediately precede the repeating group contents.

But the specification of B3 exchange, at page 11, says:
http://www.b3.com.br/data/files/76/42/6A/9B/4DA15610BE423F46AC094EA8/UMDF_MarketDataSpecification_v2.1.5.pdf

See the picture:

The picture puts 279 before 269. However, the message specification:
http://www.b3.com.br/data/files/66/95/5D/74/C8915610BE423F46AC094EA8/UMDF_MessageReference_v2.1.6.pdf
puts the 269 before 279.

My question is:

Is the picture of B3 wrong?


#2

Welcome to the wonderful world of exchange documentation. Check the XML file from the exchange, such as tempates-PUMA.xml, for the correct answer (which for the UMDF 2.0 that we use is that 269 comes first).

I’m so, so sorry that you have to deal with FAST. Good luck. :slight_smile:


#3

But I think 279 comes first

Screenshot%20from%202018-10-18%2018-46-04


#4

NoMDEntries(268) is the NumInGroup for 2 different repeating groups - MDFullGrp in MarketDataSnapshotFullRefresh(35=W) and MDIncGrp in MarketDataIncrementalRefresh(35=X). The fields under NoMDEntries(268) and their order are very different between the two. The elements you show in your note come from MDIncGrp and are in the correct order. The corresponding elements in MDFullGrp are

  • NoMDEntries(268)
  • MDEntryType(269)
  • MDEntryID(278)
    There is no MDUpdateAction(279) field in MDFullGrp since the message implies that all entries are “new”.
    From a quick scan of the [B]3 spec it appears they have it correct, although it’s sometimes vague which message they’re describing.
    Dean

#5

I believe there is a fundamental misunderstanding here. The original FIX Specification including the excerpts from Volume 1 were written with a tag=value encoding in mind. Meanwhile, there are many additional encodings available, i.e. FIXML, FAST, SBE, GPB, ASN.1, JSON. I admit that FIX has a to-do here to separate the application layer more clearly from the encodings (presentation layer) in its documentation.

So why is the order of fields in a repeating group relevant for tag=value encoding? There is no explicit delimiter of repeating group instances and no explicit end either. Hence the occurrence of the first field as defined in http://fiximate.fixtrading.org/latestEP/ serves as the instance delimiter. The sequential parser finds it and can safely assume the beginning of a new instance. The ending of the entire group is implicit as well. As soon as the parser finds a field that does not belong inside the group it assumes the repeating group to have ended.

However, all encodings except tag=value have delimiters for repeating groups and their instances, either explicit in form of brackets or implicit in form of schema information (e.g. byte length). The ordering of fields can therefore be changed and it may make sense to support byte alignment for performance reasons. Market data with FAST is one of those use cases where it makes sense. I would suggest to maintain the ordering found in FIXimate whenever performance does not play a role, e.g. with FIXML. It simply makes it easier to understand a given FIX interface. The FIX Global Technical Committee bases ordering on semantical relationships between fields. New fields are entered with this objective in mind.

To be clear, encodings other than tag=value may also not place fields outside of a repeating group as this changes the semantics of the message. But they can choose and order of the fields and nested repeating groups inside (with the caveats from above).

Last not least a comment for @aybiss: agree that FAST is quite complex and can be challenging even though it is a great encoding when bandwidth is the issue (it was at the time). Suggest to take a good look at FIX Simple Binary Encoding (https://www.fixtrading.org/standards/sbe/), a fixed length binary encoding that has removed many of the complexities of FAST and is intended for high performance interfaces (transactions or market data). It is “simply the best” as Tina Turner would put it :slight_smile: