Stef Verlinden wrote:
I'm not a technical person but to me it seems very cumbersome if such
'differences' could exist between 2 versions of the same archetypes.
This would mean that for every query one has to go into detail of
every version of that AT which could mean al lot of work.
To my understanding versions of AT's should be 'backward compatible'.
One can only add (and maybe remove) items, but never rename an
existing item. Only then a lot of unnecessary work for 'query-makers'
can be avoided.
Is this assumption indeed correct?
all,
we need to be very clear about archetype 'versions'. There are two
dimensions to the problem of 'archetype change' that need to be
remembered. Firstly, archetype development lifecycle. Before an
archetype is finally released after progressing through the quality
assurance process, it will undergo many changes as part of normal
authoring. During this period, no production data are created, and there
is no issue about backward or forward compatibility of archetypes or
queries with data.
The second dimension is to do with the kinds of change that can be made.
First of all, many variations in data can be accommodated with no change
at all - archetypes are constraint models, not cookie-cutter templates.
Most archetypes are designed to be very open. Many changes to
archetypes, including all translations, and any semantic change that
loosens the constraints can be accommodated by a 'revision'. Only
incompatible changes result in a version change, i.e. a change in the
'.v1', '.v2' etc part of the archetype identifier. Now, after an
archetype is released, such changes should be minimal, if not
non-existent. Remember: this is only incompatible changes, such as ones
that change the structure of information, make optional items mandatory
and other such things. When a new version is created, a data migration
algorithm has to be published with it.
The result of this is that new _versions_ of officially released
archetypes should be very low in number and should always have a formal
definition of how to migrate data created using an older version.
The confusing factor that people are seeing now is that due to the
current tooling, most archetype authors are creating new 'versions' when
in fact the changes are only new revisions. We are also seeing many
archetypes that have not been quality assured. These limitations are
being addressed with new tooling that will soon be available, and a
better defined version numbering system, using a 3 part identifier. One
of the things the new ADL parser will be able to do is to determine
whether a given change requires a new version or not. The algorhitms for
doing this are not trivial and it has taken some time to get them worked
out.
In production systems different archetype versions may give rise to the
following:
- automatic data migration of data from an old version to a new version
of an archetype
- automatic on-the-fly translation of data from an old version to the
form required by a new version
If either or both facilities are in operation, then only one version of
any given archetype will effectively be vsible in the database - the
latest. For situations where data created by more than one is left
intact, we consider this as if it were two archetypes. I.e. there is a
general need if you are querying 'systolic blood pressure' to find all
archetpes in which this could be recorded and to generate an appropriate
query. If let's say 2 out of 3 found archetypes happen to be two
versions of one logical archetype, this is essentially the same
situatoin as if 3 distinct archetypes had been found that carried this
data item. The key to managing this is the forthcoming online archetype
repository classification ontology which allows you to do this search.
This ontology already exists in a basic form, and is what supports the
querying at the old prototype repository at http://archetypes.com.au.
I hope this clarifies things
- thomas