2011/4/28 Heather Leslie <heather.leslie at oceaninformatics.com> > Hi everyone, > > I think you are missing some of the further complexity here. There is a > definite need for differentiation between draft and published archetypes for > which a version number alone is not enough. > Currently we are talking only about v1 archetypes and how to manage them, > and to a degree it makes sense. We certainly considered using v0.x for > drafts but it doesn't solve the downstream problems - once a v1 archetype is > published, the non-breaking revisions will become v1.1, 1.2 etc. No problem > But when we make a breaking change it becomes v2 (or v3 or v4 or 125), but > it needs to be clear that it is v2 *draft* initially and not v2 *published* > until we have completed the neccessary collaborative reviews. > > I see your point and I completely agree with it.
Using v0 to denote draft archetypes before going to v1 only solves the first iteration. When moving to v2, v3, etc. we certainly will have drafts and published archetypes for those new versions and we have to manage all them. Even when creating v1.x or v1.x.y archetypes we can need drafts prior to the formal voting/validation/publication of them. Archetypes, as a technical resource (not as a concept definition) need to have unique identifier for each minimal change. We have the archetype revision history but we should also show those changes by changing the identifiers. So, we fall back to the need of rethinking archetype identifiers to include these new requirements or change them into identifiers with no semantics. Or a third option, maybe the best one, to clearly separate between a "concept identifier" that would be the current identifier and a "resource identifier" to track every change and to, at least, warn systems that use archetypes that something has changed. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/9cdfe73f/attachment.html>
