Doesn't this create problems while using archetypes/templates as basis for the generation of data instances?
I mean, a computed attribute (for example, the EVENT offset) gets its value from already existing values or attributes of the instance class (in this example, from the time and the parent.origin). We should not create the instance if data is not valid regarding the archetype/template, but we cannot check the validity of the constrained offset while we don't have the instance complete. It seems somehow a vicious circle. An assertion here is clearly preferable, since by definition it is only applied to existing instances. David 2012/1/10 Thomas Beale <thomas.beale at oceaninformatics.com> > On 10/01/2012 08:40, Diego Bosc? wrote: > > Oh, this is the first time I have heard that functions can be > > constrained. However, AOM specifications say otherwise: > > "C_attribute: a node representing a constraint on an attribute > > (i.e. UML ?relationship? or > > ?primitive attribute?) in an object type;" (AOM specifications, page 12) > > This excludes clearly the 'stored properties'. > > > > > > That wording in the current release does exclude non-attributes. But I > think it should be possible to state constraints on computed attributes > (public functions with no parameters). It has already been implemented > and is not difficult. > > - thomas > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- 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/20120110/096b847f/attachment.html>
