>> Exactly what I mean, we must agree, which part of the version-number >> indicates a possible incompatibility concernig archetypes/RM-version. >> Bert >> > > Don't try to get too complicated. Just have a list that states that > this archetype has been validated against these RM versions. If my RM > version is in the list I okay. There aren't going to be too many RM > versions anyway. > Excuse if I come back to something which is already discussed, I have a busy day to day, no time to read all, I do that later. But I want to add some arguments to the discussion before the momentum has gone. ---------------- It is a very common policy, to assign a meaning to parts of a version-numbering regarding to compatiblity. Mostly it gets complicated when you do not use such a mechanism. In that case, you need smart code to detect the RM-version, or use compatibility tables.
If there will not be too many RM-versions, I hope you are right, but only a few can already lead to compatibility problems. There is also a rm_version in class Archetyped (archetype-details) But the problem of adding an internal version indicator is more complicated, at second thought. This implies that there can be more then one archetype with the same name, but different internal RM-version. Because Archetypes often are filebased (or database with name as key), this is not possible. If there has to be a RM-version in the archetype, it has to be in the name, or else, archetypes can no longer be file-based, which would break some systems. Bert -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090204/20c37240/attachment.html>
