Specific AOM constraint for DV_PROPORTION

Description

Does anyone believes we need a specific C_DV_PROPORTION in the AOM or AOP model?

I think DV_PROPORTION constraints are relying in the primitive constraints of the AOM.

Environment

None

Activity

Show:
Thomas Beale
June 19, 2015, 11:27 AM

Pablo, can you provide more details here? I don't know what this is about.

Pablo Pazos
June 19, 2015, 8:03 PM

My intention was to see if there is any value to have something like C_DV_PROPORTION like the complex constraints we have for DV_ORDINAL or CODE_PHRASE, or we are just fine using C_COMPLEX_OBJECT/C_ATTR/C_PRIMITIVE to contraint the internal fields of DV_PROPORTION.

C_DV_PROPORTION matches {
pk_percent|[0..1000]/[100..100]
}

Another issue that might be related to tooling: There is a dependence between DV_PROPORTION.type and DV_PROPORTION.denominator. If we allow to define individual constraints for each field, e.g. "type" and "demoninator", we need to validate that both constraints comply the dependence (if type=percent then denominator = 100).

Currently the AE generates something like:

DV_PROPORTION matches {
denominator matches {|0.0..1000.0|}
is_integral matches {False}
}

I think that's wrong because is_integral is a function. But it should be something like:

DV_PROPORTION matches {
denominator matches {|0.0..1000.0|}
type matches {pk_percent}
}

As in http://www.openehr.org/releases/trunk/architecture/am/aom2.pdf page 41.

Either way, I can specify "pk_percent" and denoninator 0..1000 (and it should be exactly 100).

Thomas Beale
June 20, 2015, 4:20 PM
Edited

In ADL/AOM2 we have ditched C_DV_XXX special classes. The current ones from ADL 1.4 are replaced with tuples. Standard ADL will take care of representing DV_PROPORTION constraints properly, but only if it is defined in the RM properly. That would mean having invariants like

type = pk_percent implies denominator = 100.0

These invariants are not sufficient in RM 1.0.2, so one potential action from this PR would be to generate a CR to fix that in SPECRM.

It would also mean that archetype modelling tools would be able to see these invariants and use them computationally to prevent the archetype author from building RM-invalid constraints.

Agree with you on the is_integral problem - I suggest you raise an issue on the Archetype Editor issue tracker.

Reporter

Pablo Pazos

Components

Affects versions

Priority

Major
Configure