A nicer approach could be as follows:
* we allow 'computed' attributes in the RM definition used by
archetype tools, which will allow archetypes to be very clear and
nice, e.g. in the case of 'offset'
* in the RM definition, we include a rule that defines the equivalence
of such computed attributes to static attributes - i.e. an expression
* when generating performing the flattening operation, and generating
the Operational Template, we replace constraints on computed
attributes with the relevant equivalent expressions
- thomas
On 11/01/2012 06:53, Rong Chen wrote:
> Hi all,
>
> I also think constraining functions, i.e. computed attributes, in the
> reference model classes can be counter-intuitive and probably
> unnecessarily complex.
>
> In clinical modelling space, a function is supposedly less obvious to
> modeler than an ordinary RM class attribute. Since the result of the
> function is derived from several member attributes and the algorithm
> is documented in the RM specs, it's reasonable to assume that a
> constraint expressed on derived values is less understood than that on
> an attribute. If a derived value is so commonly used and indeed
> necessary in archetyping, why not make it an attribute in the first
> place.
>
> In the engineering space, constraints on static attributes seem to be
> more straight-forward to work with. Default data instance can be
> safely generated by the combined definitions of archetypes/templates.
> Upon saving the data instance, the invariants, or rules in the latest
> specs, would be used against the instance for final validation. Now
> considering how to handle the constraints on functions, they can't
> really be used for instance generation since they are dependent on
> other attributes. So they would probably only be used in the final
> validation just as rules/invariants. So indeed, why not implement
> these function constraints as invariants/rules to start with?
>
> In summary, I would vote for only allowing constraints on ordinary,
> static attributes. Use invariants or rules to achieve same effects as
> constraints on functions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120115/e0ea501a/attachment.html>
