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'.
2012/1/9 Thomas Beale <thomas.beale at oceaninformatics.com>: > > In ADL/AOM, constraints can be made on computed properties as well as > stored ones. ?If you look at the spec, EVENT.offset is computed as > time.diff(parent.origin). Making a constraint on EVENT.time, which is > the absolute time (which is what you want in the data) is annoying > because you want to constraint on relative time, not absolute time. It > would mean creating constraints in the rules section with an equivalent > expression, i.e. > > .../some/path/to/event[5 min]/time - .../some/path/to/event[5 > min]/parent/origin <= PT5m > > - thomas > > On 09/01/2012 11:41, Diego Bosc? wrote: >> When I was trying to validate an archetype with the reference model >> (openEHR-EHR-OBSERVATION.apgar), I found something strange on all >> 'event' archetypes. >> The EVENT class has a function (method) that calculates the offset. >> However, in that archetype the offset was restricted as if it was an >> attribute. >> What is the sense for this? Shouldn't this restriction be expressed as >> an assertion over the different attributes? (that is, a restriction >> that must be checked at runtime as it is a result from a method). >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
