Tim Cook wrote:
There are VERY specific guidelines as to what and what does not
constitute various archetype version changes. Maybe/maybe not these
should be reviewed in reference to RM versions?
they are under review, that is for sure - we can discuss this a bit more
when the template & ADL 1.5 specs move on a bit more. But the rules are
pretty stable even now, mostly based on what ADL1.5 says 'conformance'
means. But lets leave this to another thread...
Since we all have very good crystal balls.....
We can see a future where at RM version 2.5 there are significant
differences to RM version 1.0.2.
well - there are also rules about the RM as well. Ideally, even over
major releases, e.g. 1.x -> 2.x, the core of the current reference model
will remain backward compatible, meaning:
* new attributes could potentially be added, but they must be optional
* mandatory attributes can't be removed (later software might
sometimes see a data item in old data corresponding to an optional
attribute that was removed)
* attributes could only be changed in such a way as to make them a
broader constraint, e.g. a mandatory attribute could be made
optional (later software will handle older data, which is the
effect we want)
These rules are intended to be hard and fast across sub-major and minor
releases, but I suspect they will apply over major releases as well. If
they didn't, then all we can say is that archetypes are only guaranteed
to work within a given major release, e.g. 1.x - which might not be true
for many archetypes, even if there were breaking changes, if those
archetypes did not happen to reference the broken part of the model.
The reason I think we realistically have to allow breaking changes
across major releases is not due to the core models of today, which seem
pretty safe. It is new additions with which we have less experience,
e.g. two areas I can see being added to the RM are process/workflow, and
'study' data (i.e. the CDISC idea). I don't imagine we will get these
right first go, so we would need to allow them to be fixed over a major
release.
However; we have Mary in rural Montana USA, a patient a Dr. Jones's
office (believing strongly in future proof) and she moves to a new city;
let's say Atlanta, GA. Where Dr. Brown (ALSO! believing strongly in
future proof) has been on top of things and is now at RM version 2.5.Well, Dr. Brown gets Mary's record from Dr. Jones and discovers that
some of the archetypes that were built 15 years ago in 1.0.2 RM just
simply do not display or worse yet cause unknown type errors and his
application(s) crashes.Future Proof? Hardly!!!!!
well - it depends on the position we take on whether breaking changes
are allowed or not.
Doesn't seem much different from the migrating SQL data base schema
problem does it?
probably somewhat better - you touch almost anything in a relational
database and the software breaks....
So I believe that we as a community should take multiple courses. I
want to emphasize that we should take THEM ALL!First: an archetype tool developer MUST record the RM that an archetype
was built against.Let's say RM=['1.0.1']
I don't object in principle of course - my question earlier was simply:
how do you know which minor version to put? The archetype may have been
built during the reign of 1.0.1, but gets published at 1.0.5 (4 minor
versions got done during one week maybe). According to the logic above,
only the major version number should be recorded....
(okay so I apologize for my Python syntax, but it's easy to read).
Second: An archetype is edited (whether it's version changes or not)
against a tool using RM 1.0.2.The RM = is now RM=['1.0.1,'1.0.2]
do you mean a copy is edited? If multiple copies are edited by different
tools (including the definitive copies in online repositories) some will
get the 1.0.2 added, some won't, due to older tools. Then you have
multiple copies of the same archetype with different meta-data. And
plus, a publishing event is forced for every archetype whenever a new
minor reference model release is made.
At some point this archetype has now been validated against 2 RM
versions. It should work with both RM versions and the consumer
(application developer knows it).Third: The application developer has a choice to make. Either read the
list and support backwards compatibility based on the last known RM
version or simply be NON-FUTURE-PROOF and reject the data.At the very least, the archetype contains the information needed to let
the application know what it expects in order to be rendered and
processed.So in essence, I TOTALLY disagree with Tom's statement:
so let me adjust that - depending on the rule we set in the community
for changes over major releases, we should record the RM major release
number only in an archetype.
Any takers?
- thomas beale