Hi Ian, > I think we do have very good versioning / revisioning rules and CKM > has implemented these within its comparator function when we upload a > modified archetype. >
What I meant was that: if we, in the future, have several CKMs around the world, maybe forming a hierarchy or not, we need a clear specification of the versioning rules for this distributed CKM. I don't know for sure if the versioning issue is solved or not, or if it's solved only at the CMK or if it's part of the specifications. What we need is the latter. Not so long ago there was a very interesting discussion about that: http://www.openehr.org/mailarchives/openehr-technical/msg05797.html > There is active work exploring how to tighten up the governance > issues, especially around namespaces but I think we are pretty close > to having this worked out. > I would love to see that. Can you point me to some information or discussions about those issues? > Once you consider the potential dependencies of templates, archetypes, > specialisations and termsets, there are some interesting challenges > ahead in understanding how best to keep good blend of agile > development and the kind of stability that vendors and other projects > will require. > Is this a closed discussion? I would like to help. > I think Release Sets will play an important part here by giving > different projects a fixed, coherent set of artefacts to work with, > even as the leading-edge development moves on. I think it is much more > likely that connections between repositories will be through Release > Sets than by full 'current' access. We are starting to look at this > issue of 'federation' in CKM but current thinking is that a simple > view of, or reference to, assets in another repository is really not > going to help real development very much. The key issue is how to > request and acheive change in a non-native artefact, and how to handle > the inevitable mismatch in development cycles between native and > non-native artefacts. > The Release Set is a nice idea. but I think CKMs should support individual artefact commits also. > Although the Ocean CKM is a pretty unique product for now, I am sure > alternatives, quite possibly open source, will emerge but as David > Ingram suggested this kind of functionality is complex and will take > time to develop. > Yep, it would take time, but is necessary if we want worldwide impact. Maybe is not only necessary, but strategic. > I would be much more interested in starting with a light-weight > community repository tool, without the burden of tight governance > requirements of a CKM-like application. I think this can get started > with relatively low development requirements based around Derek's > Snowcloud template tool. > We (the Open EHR Gen team) have developed very basic service oriented repository, a simple web oriented template editor that communicates with the reposiotry to load archetypes and templates, and save templates. It would be nice to try other groups tools and see how we can join efforts. regards, Pablo. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20110908/55b86760/attachment.html>
