Yes, the reason I said to move it to resource_description was because lifecycle_state was already there. I agree that version_status must exist.
2014-01-27 Thomas Beale <thomas.beale at oceaninformatics.com> > On 27/01/2014 13:37, Diego Bosc? wrote: > > Just a couple of comments: > > Do really is_template & is_overlay need to be mandatory? > > > well they are only mandatory due to being Booleans, and in standard > programming languages, Boolean (or bool or whatever) is a builtin type that > is always there. In XML and other serialisations, it's true that anything > can be optional (normally absence = False for Boolean). I should probably > change this to reflect that. > > > I would say that they can be optional if you are dealing with > archetypes (assuming that all archetypes are just archetypes by default). > What does exactly 'is_overlay' refers to? > > > an overlay is a cut-down archetype that is used as a template-specific > slot-filler to provide the overrides on a standard slot filler. E.g. say > you want to put 'symptom' CLUSTER archetype in a CLUSTER slot for template > T, but just for that template you also want to remove 3 of the 5 data > points of the symptom structure. So you create a specialised (1.5) > archetype that does that just for that template. It's the same as any other > specialised archetype, except it has almost nothing in the description > section, because it gets all that from the template. So an overlay can't be > used standalone, but obviously, tools could convert one to a real > archetype. > > In 1.5, a template is essentially a specialised archetype with a bunch of > other filler archetypes, templates and / or overlays (maybe all overlays). > > > > Also, I think that you could argue that version_status is more suitable > to be placed into the resource_description instead of where it is now. > > > version_status, or something equivalent is needed with the version_id > attributes, so that the full version id can be constructed, e.g. 1.0.4-rc28 > - the version_status is what tells you that it's an 'rc' (release > candidate), full release (1.0.4), uncontrolled additions (1.0.4+u88) and so > on. It's related to the lifecycle_state, which has more values like > 'initial', 'obsolete', and so on, according to this state > diagram<http://www.openehr.org/wiki/download/attachments/5996562/artefact_lifecycle_versioning.png?version=1&modificationDate=1366562248000&api=v2>. > There is overlap but it seems unavoidable to me. > > - thomas > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140127/9b427844/attachment-0001.html>
