Data type compatibility assurance

[pavel.kirienko]

But, we can still open a subject in the dynamic DSDL range with a data type that has a default ID in the static data range, right? I don’t see much reason to disallow this.

While my arguments for its disallowal are weak, the arguments for the opposite seem even weaker. When not sure, always lean on the side of simplicity (which in this case means disallowal). I wrote about this here: On Subject/Service ID ranges

@pavel.kirienko

Upon closer review of the new concept of Subject and Service ID one might see that the requirement that the static ID to be changeable at runtime becomes unnecessary if we were to avoid assigning static IDs to data types where it might require changing in the first place.

This means that once you’ve decided to stick a static ID (N.B.: “static”, not “default”) to a data type (either service or message), it will be available only under that ID. Any user of that data type will immediately see that and be relieved of extra work that dynamic ID require. If that turned out to be a mistake, the designer of the data type can always fix it by releasing a new major version without the static ID.