# Constraints on class methods

**URL:** <https://discourse.openehr.org/t/constraints-on-class-methods/15125>\
**Category:** Technical (archive)\
**Created:** [9 January 2012 11:41 UTC](https://discourse.openehr.org/t/constraints-on-class-methods/15125 "2012-01-09T11:41:29Z")\
**Posts on this page:** 7\
**Page:** 2

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [15 January 2012 15:15 UTC](https://discourse.openehr.org/t/constraints-on-class-methods/15125/21 "2012-01-15T15:15:41Z")

</div>

We don't include them because noone has ever wanted to constrain them,  
so currently it would serve no purpose, but obviously we could include them.

- thomas

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [15 January 2012 15:29 UTC](https://discourse.openehr.org/t/constraints-on-class-methods/15125/22 "2012-01-15T15:29:58Z")

</div>

there is already an assertion in the RM. Where/how do you want to use it  
in an archetype?

- thomas

---

<div class="post-metadata">

**Author:** ![yampeku](https://discourse.openehr.org/user_avatar/discourse.openehr.org/yampeku/32/25_2.png) [@yampeku](https://discourse.openehr.org/u/yampeku)\
**Post date:** [15 January 2012 15:52 UTC](https://discourse.openehr.org/t/constraints-on-class-methods/15125/23 "2012-01-15T15:52:31Z")

</div>

I'm not sure if I have understood your question, but there isn't  
already assertion support on the AOM?. just put an assertion of the  
restricted and desired condition (in this case something like this:  
"|event.time - history[atxxxx].origin|=P10M")  
I don't really see the big issue about defining things like this

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [15 January 2012 21:05 UTC](https://discourse.openehr.org/t/constraints-on-class-methods/15125/24 "2012-01-15T21:05:43Z")

</div>

Technically there isn't. It's about clarity for modellers. The above  
makes perfect sense to us technical people, but now we can't have a  
simple constraint on Event.offset, which clinical people can understand,  
it means we have to have some more complex UI interface in the modelling  
tool, so that the constraint is comprehensible to normal mortals. That;s  
why I am more interested in a simpler constraint (based on a computed  
property) and putting the expression further back in the tool structure.  
But that's just my view; I am interested to hear other opinions - if  
everyone is against computed attributes then we need to find a clean  
solution for this.

- thomas

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [16 January 2012 11:49 UTC](https://discourse.openehr.org/t/constraints-on-class-methods/15125/25 "2012-01-16T11:49:24Z")

</div>

I found that offset was a stored value at openEHR RM 0.95 (back in 2005), but then it became a computed method.

2012/1/15 Thomas Beale \<[thomas.beale@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com)\>

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [16 January 2012 12:12 UTC](https://discourse.openehr.org/t/constraints-on-class-methods/15125/26 "2012-01-16T12:12:35Z")

</div>

A possible problem I can envision is that this opens the door to the creation of invalid archetypes without the possibility of validating them at design time.

A quick and dirty example just to get the idea. In an archetype, the HISTORY.origin is fixed to “T10:00:00”, a child EVENT.time is fixed to “T18:00;00”, and finally the EVENT.offset is fixed to “PT5H”. Offset is clearly not valid regarding time and origin, but we do not know it since the expression to calculate it is not explicit anywhere (only at the RM specifications).

David

2012/1/15 Thomas Beale \<[thomas.beale@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com)\>

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [16 January 2012 13:38 UTC](https://discourse.openehr.org/t/constraints-on-class-methods/15125/27 "2012-01-16T13:38:39Z")

</div>

that problem can occur even with just two normal attributes, if they  
happen to have a mathematical relationship...

- thomas

[Previous page](https://discourse.openehr.org/t/constraints-on-class-methods/15125.md?page=1)