Schemas are versioned and breaking changes are expected, so a consumer can pin a version and adopt a schema early without being trapped. What is missing is the step from a pinned old version to a new one.
Asked for: a simple way to declare how to migrate between two versions of a schema, so that instance data can be carried forward automatically where the change permits it.
Observations from the discussion:
- Much of this should be automatable. Given both schema versions and their documentation, a migration script can be generated, then validated by running it over real data and checking the result against the new schema.
- It is not always possible without extra information. A rearrangement or a non-critical addition is mechanical; a change that introduces meaning not present in the old data is not.
- The practical guard is to avoid schemas with internal ambiguity in the first place, so that a migration does not have to guess at intent.
Versioned schemas are what makes any of this tractable, since both sides of the migration are precisely defined.
Raised at the MaterialsCommons WP2 bi-weekly, 21 September 2026.
Schemas are versioned and breaking changes are expected, so a consumer can pin a version and adopt a schema early without being trapped. What is missing is the step from a pinned old version to a new one.
Asked for: a simple way to declare how to migrate between two versions of a schema, so that instance data can be carried forward automatically where the change permits it.
Observations from the discussion:
Versioned schemas are what makes any of this tractable, since both sides of the migration are precisely defined.
Raised at the MaterialsCommons WP2 bi-weekly, 21 September 2026.