Proposed renaming of //MsgType@MsgID and //Components@MsgID element name

, ,
1

Imported from previous forum

2

The //MsgType@MsgID and the //Components@MsgID represent a unique integer identifier for messages and components – the values are globally unique. We are proposing that we change this identifier to be Internal Component Unique Identifier InternalComponentID The recommendation is based upon the concept that messages are specialization or extension of a component (collection of fields) and that the name Component ID more accurately reflects the payload. We believe this will also reduce the confusion between MsgID (unique integer id for messages and components) and MsgType (unique character enumeration for messages only). Are there any concerns or issues with this?

3

Jim,

a thought on ID ranges for components. It can make sense to use both tag IDs and component IDs in a binary wire format that does not use FAST templates. If the ranges overlap then you need another way to distinguish whether you are looking at a field or a component. It might be worth to separate the ranges, i.e. use 40,000 and above (reserved for FPL) for components. You need an extra byte (3 instead of 2) for such high numbers if you work with stop bits (2^14 = 16384).

We have good experiences with this approach in our proprietary encoding. The message is a non-repeating component consisting of fields and (repeating) components. A repeating component starts with the component ID followed by 1 or more instances. Each instance is a again a component with the same ID as the repeating component itself. As we include length information as well, we do not need explicit delimiters and the user can skip an entire repeating component, an individual instance or an individual field. This is useful for backward compatibility to allow a user to skip components and/or fields he does not recognize.

Regards,
Hanno.

The //MsgType@MsgID and the //Components@MsgID represent a unique
integer identifier for messages and components – the values are
globally unique.

We are proposing that we change this identifier to be Internal Component
Unique Identifier

InternalComponentID

The recommendation is based upon the concept that messages are
specialization or extension of a component (collection of fields) and
that the name Component ID more accurately reflects the payload.

We believe this will also reduce the confusion between MsgID (unique
integer id for messages and components) and MsgType (unique character
enumeration for messages only).

Are there any concerns or issues with this?