DV_TEXT allows free and coded text if needed for COMPOSITION.context.location
That can be set at runtime or archetyped.
Current string doesn't allow much archetyping besides setting a regex constraint.
Using codes simplifies mapping to other specs (XDS metadata, CDA, etc.)
This might be a good change, but it is a breaking one, so would need to be openEHR 2.x
Not sure about the strategy of versioning breaking changes. In other projects not all of those generate new major versions, it depends on the level of breaking current specs. This in particular is very backwards compatible and with a clean migration guide might be suitable for a minor version release.
But if the strategy is all breaking changes go to new major versions, I'm ok with that.
Well it would break the XSD, and at least some JSON in the REST API, and at least some DBs, so although logically it is a small change, the breakages would be severe in real systems already using all those things.
I agree, but are we not versioning XSDs and other ITS artifacts to match the release version of the spec?
If all is versioned, there is no break or migration needed until an implementer wants to update to a new version of the spec. The same happens when a new version of an API is released and client apps don't update right away, everything still works and no changes on systems are needed until the client wants to update to the new version of the API. IMO no change to the spec should break any working system, if the release set is versioned correctly.
1. We should have a new version of the XSD for every change to the model, and the XSD should match that specific version of the model, with or without breaking changes. That applies to major, minor and revision versions.
2. Implementations should be compliant with a specific version of the spec.
Maybe we are not managing releases so that can be possible, or I don't see something obvious for others. BTW this is not about this specific CR, is about how we manage versions and release sets for the whole spec.