Hi David,
Thanks for this, though I think these are still draft specifications. I had
some input into that document but with experience I am not sure the revision
rules really work for .v0 archetypes though the .v0 idea itself is useful.
The problem is that any structural version changes would force us to move
from v0->v1, which is what I think we need to avoid for these first draft
archetypes. Once an archetype is published, the rules suggested (mostly)
work just fine
Ian
Dr Ian McNicoll
office +44 (0)1536 414 994
+44 (0)2032 392 970
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com
Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org
On 27 April 2011 10:15, David Moner <damoca at gmail.com> wrote:
>
>
> 2011/4/27 Ian McNicoll <Ian.McNicoll at oceaninformatics.com>
>
>>
>>
>> Would calling first draft archetypes .v0 help to highlight their
>> fragility?
>>
>>
>>
> In fact, that is what the specifications say. Our archetype editors should
> use 0 when creating a new archetype.
>
> (Knowledge Artefact Identification specifications)
>
> .v0 rule: all archetypes have this version on initial creation, before
> being accepted by the
> collaborative authoring environment;
>
> revision id rule: revision number starts at 0 and is incremented whenever a
> backwards
> compatible change is made that affects the structure ? by widening
> constraints and/or adding
> new nodes;
>
> commit id rule: commit number starts at 0 and increments for any change at
> all to an archetype,
> including changes to meta-data, addition of translations and so on.
>
> An archetype will start its life as a ?v0? artefact, and with no namespace.
> In this form, it can have any
> number of revisions and commits. It may be maintained for some time outside
> a Publishing Organisation,
> or it may be offered to a PO, where it will initially become part of an
> ?alpha? development area.
> where it will remain until its identifier and location in the package and
> Library structure is stablised.
>
> Once stable, an alpha archetype will migrate to the main ?dev? area, where
> it will be given a namespace
> prefix and have its version incremented to ?v1?. At this point it could be
> published into the
> ?release? area, or alternatively, further development may occur before
> publishing. Whenever the revision
> is changed, due to a backwards-compatible structural change, the archetype
> should be re-published,
> enabling the community to have access to the latest form of the archetype.
>
> During development, each change will increment the commit number. Whenever
> an archetype is published,
> the commit number is reset to 0.
>
>
>
>
> --
> 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)
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110427/1aa65cb0/attachment.html>
