Multiple occurrences of a tag within a message

1

Hi,

I have one question regarding the multiple occurrence of a tag in a message. FIX5.0 SP2 Vol.1 states:

A tag number (field) should only appear in a message once. If it appears more than once in the
message it should be considered an error with the specification document.

The special case are of course repeating groups which aren’t explicitly mentioned here.

Now in the FIX TagValue online spec we cannot find the sentence above. Instead there is the following statement:
(https://www.fixtrading.org/standards/tagvalue-online/#message-structure)

A tag (field) must appear at most once in a message, except when the tag appears within a repeating group.

Questions:

  1. So does this mean I could have the same tag appear in multiple repeating groups? E.g. tag 123 could be part of repeating group NoAAA and NoBBB?
  2. And does this mean I could have the same tag appear both in the parent message AND in a repeating group?

(Just as a side note: QuickFIX/J seems to support both cases from question 1 and 2, but this is probably just coincidence.)

Now I’m no native english speaker but one could also understand the statement like this:
When the tag appears within a repeating group it is allowed to appear more than once (not only as part of the repeating group).

This could be perfectly fine because you can get access to the tag via the parent message and via the repeating group. You just need to address them differently.

The statement from the spec does not explicitly disallow this but I assume what it really tries to say is the following:
A tag (field) must appear at most once in a message, except when the tag appears within a (as in: the very same) repeating group.
I guess otherwise there weren’t so many tags with same meaning but different names like e.g. PartyID, PartySubID, NestedPartyID, …

Thanks in advance,
Chris.

2

Maybe the easiest explanation is to take FIXimate. If you display any FIX message and expand all of its components, you must not see a tag number or field name twice. FIXimate shows the definition of a message and not the wire format of an instance.

The quote from the refactored online spec refers to the wire format of any instance of a message encoded in tagvalue syntax. It means that inside the wire format of a single repeating group a tag (field) may appear more than once. In fact, if you have more than one instance of a repeating group, you must have at least one tag (field) occur as many times as there are instances (given by the NoXXX field).

This concerns me as FIX does not support it. Maybe others can comment on this in this thread. FIX does not use the term “parent message”. We rather talk about root fields of a message and repeating group fields.

You are right about the reason for the large number of similar sounding tags for parties. However, PartySubID does not belong in that list, they should be as grouped as follows:

  • PartyID, NestedPartyID, Nested2PartyID, …, RootPartyID, PartyDetailID,…
  • PartySubID, NestedPartySubID, Nested2PartySubID, …, RootPartySubID, PartyDetailSubID,…
  • PartyIDSource, …
  • PartyRole, …
  • …
3

Thanks for your reply, Hanno.
W.r.t. QuickFIX/J: I think the fact that it is supported is an implementation detail how the fields are stored internally in QFJ. The field presence is only checked on root level and within a repeating group but not across all repeating groups of a message.

4

Two follow-up questions:

  1. Do you know why it was (decided a long time ago) to have this restriction with having a tag only appear once per message? I especially mean across all different repeating groups. Why it is not allowed to have say a Price tag in two distinct repeating groups?
  2. Is Orchestra able to enforce this restriction?

Thanks again.

5

@christophjohn thanks for the question. The restriction is actually limited to the tagvalue encoding. For example, the parties component is “Pty” for all instances in FIXML, the XML syntax/encoding of FIX. This is due to the fact that the XML syntax has an unambiguous structure with a distinct path to every occurrence of a component or field. The XML names only need to be unique within the same element.

For tagvalue, a parser needs to know when a repeating group starts and ends. The NoXXX field marks the starting point and a field that is not part of the group marks the ending point. There are no explicit delimiters for repeating groups in tagvalue and components (non-repeating) are not visible in the wire format at all. Technically, you are probably right that a Price tag could exist in two distinct repeating groups without causing a parser issue but I do not see the benefit to allow this exception to the rule. You cannot allow it for two adjacent levels, e.g. root + nesting level 1 or nesting level x + nesting level y.

Orchestra should be independent of any specific encoding although it has, for example, information related to the FIXML encoding (attribute abbrName). There is a validator utility for Orchestra (https://github.com/FIXTradingCommunity/fix-orchestra) that checks conformance to various aspects. It currently does not check for tag/name duplicates, i.e. this is manually done as part of the implementation of an Extension Pack (https://www.fixtrading.org/extension-packs/) when adding new fields.

The Orchestra Technical Standard (https://www.fixtrading.org/standards/fix-orchestra-online/) could be enhanced to contain an attribute to identify conceptually identical components and fields where the difference in tag number and field name is solely to avoid a duplicate in tagvalue encoding. If you are a FIX member, you can join the FIX Orchestra Working Group (https://www.fixtrading.org/groups/fixorchestra/) to enhance the standard and its tools. You can also get engaged in the public GitHub projects (https://github.com/FIXTradingCommunity). Especially the tools should be a community effort as FIX is largely a volunteer organization and has limited funds.

1 Like