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
