# Data type compatibility assurance **URL:** \ **Category:** Development & Maintenance\ **Created:** [October 16, 2018, 6:32pm UTC](https://forum.opencyphal.org/t/data-type-compatibility-assurance/196 "2018-10-16T18:32:47Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [October 17, 2018, 4:10pm UTC](https://forum.opencyphal.org/t/data-type-compatibility-assurance/196/3 "2018-10-17T16:10:31Z")
> 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](https://forum.opencyphal.org/t/on-subject-service-id-ranges/195) > [@On Subject/Service ID ranges](https://forum.opencyphal.org/t/on-subject-service-id-ranges/195/1): > > 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. --- _[View the full topic](https://forum.opencyphal.org/t/data-type-compatibility-assurance/196)._