Extensibility of the Template ID about fix-simple-binary-encoding

[donmendelson]

Added enum value is not explicitly mentioned in section 5 of the spec. However, the metadata provides for versioning of enum values, just as it provides for versioning of fields. The schema entity <validValue> has sinceVersion attribute to tell in which schema version the enum value was added.

sinceVersion - Documents the version of a schema in which a value was added

There is no problem going from old producer to new consumer. However, if the producer is of a later version than the consumer, and it sends a newly added enum value, then the consumer will consider it an invalid value.

I would expect the decoder to pass the exception up to the application layer for appropriate handling. For example, if OrdType value J=Market If Touched is added to a schema, and the consumer does not recognize it, then the application should return an order rejection with reason order type not supported, even if it does not know what "J" represents. Note that this is not strictly a versioning problem, however. It should have the same exception handling even if "J" was never added to the enum but was sent in error.

[adkapur]

Hi Don,

A couple of questions regarding this particular statement --> "A repeating group may be added, but only after existing groups and if there are no subsequent variable data elements at the end of the message"

a) Does this rule apply to individual fields as well described in this statement? --> "Fields may be added to either the root of a message or to a repeating group, but in each case, they must be appended to end of a block". Couldn't individual fields be added to the root of a message regardless of whether there are variable data elements at the end of a message?

b) What happens if we add a repeating group after existing groups and there are variable data elements at the end of the message? Will this break compatibility and force all consumers to upgrade to the latest schema version?