Backward Compatibility Question

[adkapur]

As per the below mentioned paragraph listing backward compatibility rules it is not clear what happens when for an already existing field we keep the same data type and offset but we just change the rule to make the data type optional rather than required

For example if we change the data type from uInt8 to uInt8NULL then we would expect this to be a backward compatible change since we are not changing the wire format or offset for a field using this data type and the only change is that the null value of 255 can be sent

This is happening since we are using the data type to represent whether a field can be construed as optional or required rather than the presence attribute of the field itself

Could we please add this clarification to the specification?

[donmendelson]

As worded, your comment about making a datatype optional only applies to SBE version 1.0. In version 2, presence is only an attribute of fields, not datatypes.

Clearly, changing presence from optional to required should not be allowed without notifying all users of the new requirement. In changing from required to optional, you are in effect loosening validation of messages. You could do that without changing the message template. The down side for uninformed users is they may be doing a bit of extra work to always populate the field when it is unnecessary.

In your case, is it a case of a conditionally required field, or are you always going to ignore the formerly required field? In other words, is it a case of a deprecated field?

[adkapur]

Yes correct agreed this is relevant only for version 1.0 and not version 2.0

This is not a conditionally required field nor a deprecated field but instead it was a required field which is being made optional

That is also what we thought that it does not require a message template change but we would just like to add this note to the SBE version 1.0 specification