v2+ Vocabulary
0.2.0 - Working Draft to present the concept ideas (FO)
v2+ Vocabulary - Local Development build (v0.2.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Originally, i.e. during the v2 Tables Project we have used an integer to denote the version of a table with regard to its content. That implies, that incompatible next versions need to have a different base name respectively OID. However, it is hard to further argue in this direction.
Formerly, the project decided to use positive integers to version tables. Consequently, a new version is expressed by increasing this number by 1. Unfortunately, a version change does not tell anything about the type of change, i.e. whether it is major or only minor, or compatible or incompatible. Incompatible changes are introduced by new OIDs and symbolic names. This ia hard to maintain correctly.
Versioning has to be independent from the base version of the standard. Therefore, semantic versioning semver.org seems to be reasonable, but it requires detailed inspection of all tables.
That implies changing the version information for tables from integer to major (integer) + minor (integer) + patch (string).
Standard translation from old to new:
| old | new | |
|---|---|---|
| empty | -> | 0.0.0 |
| x | -> | x-1.0.0 |
It is important to note that incompatible changes in a codesystem require a specific notation. Major changes in semver does that!
| type | explanation | major | minor | patch |
|---|---|---|---|---|
| symbolic name | a short symbolic name for usings that a specific concept domain, value set or codesystem | |||
| OID | a unique identifier introducing the origin | |||
| namespace | useful? |
Is it necessary to have different symbolic names for a new major version for semantic incompatible changes?
It is unclear what namespaces are good for in this project/endavour?
tbd