From a governance point of view, I believe it is clear that the v2
route is the cleanest option here.
And in a general way I also agree with your concerns, Diego!
I think that my suggestion of deprecating old and adding the new
elements, can only make sense if we can model the new elements in
Hello,
If the archetype introduces incompatible changes with the existing version,
then no discussion it is possible: a new v2 has to be published after the
proper review rounds. Then the question is what happens to v1. Being
purist, v1 should be marked as obsolete (still usable at your own risk)
Would they be alternatives of the data type or just new elements at the
same level? I see problems with both: if you create an alternative on data
types probably you won't be able to add bindings to it, and if made a
another element then you don't have an easy way of telling what corrects
(you co
Hi Heather,
Instead of removing the incorrect UCUM unit and the old modelling
patterns completely, would it be possible to mark these bits as
'deprecated' in some [informal] way in the ontology?
This way you could make the desired changes and republish as a minor
revision of version 1.
For a
4 matches
Mail list logo
