Ian, Joy is a good thing, but once an archetype is used in production, one must be able to find that archetype back, and proof that this is the same. Not a revision, not a version, but that specific archetype.
I guess every informatic-specialist will agree on this. But this is an easy requirement, check the MD5. Having an revision does not need to mean that the pre-revision does not anymore exist. It is something that should coexist with the new revision, which can be recognized as an new revision and have the precedence on new development, but the old version should remain available. Things will really get complicated if we have to check what the difference is between the archetype of a stored dataset, and the X-th revision of that archetype. I don't think we should want these complications. I do agree that changing archetypes while using them in an application can cause problems. But also, using different versions of an archetype inside one application is not that complicated. Just regard them as different archetypes, and you are half way. The strict MD5 will help you doing so. Mistakes are not possible. That is good news. Strict MD5 checking will help the application-builder. Best regards Bert Verstuurd vanaf mijn iPad Op 8 jan. 2013 om 21:42 heeft Ian McNicoll <Ian.McNicoll at oceaninformatics.com> het volgende geschreven: > Hi Bert, > > I can understand Tim's point from an implementation perspective, and it > really all depends on what you mean by 'an archetype' - is this a Version of > an archetype, a revision of an archetype or a specific build of an archetype. > I have seen enough real implementation of openEHR to be confident that the > version/revision/build rules work very well, in terms of clearly defining > breaking and non-breaking change. One of the joys of openEHR development > is slipstreaming in a revision archetype into a running system and watching > it carry on running safely but able to support the expanded dataset afforded > by the new revised archetype, without having to change any database schema or > legacy queries. On the other hand, I can also understand that others might > want to take a different view in certain mission critical areas of specifying > a specific revision or even build of a particular archetype for data > collection and querying. Any proposals have to support both perspectives. > > The problem with the strict MD5 approach is that you are going to have to > update all of your software and query references every time you change your > schema and effectively use a 'new archetype', in many respects this is even > worse than the RDBMS approach which at least generally allows new columns > without breaking queries etc. > > So, I think I probably disagree with Tim, except in the sense that I think we > can have the best of both worlds if we adopt a sufficiently flexible id > policy that lets implementers specify the exact degree of control they want > to apply. > > Regards, > > Ian > > > > > On 8 January 2013 19:30, Thomas Beale <thomas.beale at oceaninformatics.com> > wrote: >> On 08/01/2013 19:12, Bert Verhees wrote: >>>> But I also see your problem of development, testing, data becoming useless >>>> because MD5 keys are changed because of archetypes revisions. >>> >>> A few days ago Tim Cook wrote on this list: If an archetype is used, it is >>> fixed, it may never change again. >>> There is something to say for that. >>> >>> Maybe it is just right that you cannot use a revised version to >>> retrieve/interpreted older data. You should use the original archetype, >>> identified by the MD5 key. >>> >>> I think this is a strong point. >> >> that is more or less what we do in our own implementations, and it has taken >> some time to work out even how to make this work properly. For example, >> doing an MD5 of the whole archetype actually doesn't work. You have to first >> generate a canonical version containing only the 'stuff that matters'. Then >> MD5s can be useful. But we also need a proper 3-part version identification >> system. MD5s don't replace this, they just tell you that the copy you have >> of X is really X (assuming X's MD5 is published in a place you trust), or >> else a guaranteed equivalent of X (e.g. in Dutch). I.e. the usual integrity >> check. And/or non-repudiation, if you including signing. But getting the >> definition of the canonical form is not that easy. >> >> Anyway, there are two useful docs that I and Ian McNicoll will get posted >> ASAP: >> a revised proposal for versioning and identification >> a proposal for lifecycle management >> These will just be proposals, and we are aware that others here may have >> better ideas. They are welcome to critique the proposals and / or post >> alternatives. Pretty soon we will have a good specification on this. >> >> - thomas >> >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > > > -- > Dr Ian McNicoll > office +44 (0)1536 414 994 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > > Clinical Modelling Consultant, Ocean Informatics, UK > Director openEHR Foundation www.openehr.org/knowledge > Honorary Senior Research Associate, CHIME, UCL > SCIMP Working Group, NHS Scotland > BCS Primary Health Care www.phcsg.org > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20130109/a06c6942/attachment-0001.html>
