Point_Interval vs. Proper_Interval vs. Interval types

Specifications
1

I’m in the process of reviewing the data_types and aom specs in detail for the conformance test cases for data validation, and I’m finding little things that make some noise and would like to discuss to understand them better.

Until RM 1.0.3 we had the assumed type Interval that is concrete Support Information Model

Then in RM 1.0.4, when the support classes were moved to the foundationspec (Foundation Types) two subclasses Point_Interval and Proper_Interval were introduced as concrete classes and Interval became abstract.

From the parsing point of view, when something like P3W…P3W is parsed, the parser should check if the values are the same to be able to create a Point_Interval instance instead of a Proper_Inverval. Similarly with P3W…P4W, the parser needs to check the values are not the same in order to create a Proper_Interval instance.

This clearly complicates implementation, I mean the need of checking the values to be able to instance the correct class, I would argue depending on values to know the class type might not be the best option.

Another issue I see with the new classes is the Multiplicity_Interval extends Proper_Interval hierarchy. Multiplicity_Interval is “An Interval of Integer, used to represent multiplicity, cardinality and optionality in models.”. With this definition, I think 1..1 is a valid multiplicity for cardinality, etc. but it’s not a proper interval since lower != upper in a Proper_Interval.

I would like to understand the rationale behind the new model, I’m sure there is a requirement somewhere that I don’t see and might be the key of this newer model. The only description I see is:

“To support the common need for defining times in models that could be either a fixed point in time or a time interval, the classes Point_interval<T> and Proper_interval<T> are provided.”

But that doesn’t seem enough to support these new classes. Since it’s implying there is some time requirement that can’t be satisfied just with date/time/duration classes (?) and need an interval to support a point in time, IMO feels weird.

In terms of design, I would have just one concrete Interval class and a method to check the condition like is_proper_interval(): Boolean -- true if lower < upper, false otherwise, and Multiplicity_Interval just inherits from that one setting the T generic to Integer. I think complies with requirements and doesn’t depend on the types to instance different classes.

Any input is welcome,
Thanks!

2

First thing to understand is in the first para of the Foundation Types Overview:

The openEHR Foundation Types (org.openehr.base.foundation_types package) consists of generic low level types assumed by and used throughout the openEHR components and specifications. The types described here are specified in order to establish the names and minimal semantics of typical standard classes, as used by all other openEHR specifications, and to provide a mapping point into implementation technologies.

This logic goes back to the start of openEHR.

So the idea is that if in some other part of the spec (EHR IM for example) there is a need to state an invariant like not some_string_field.is_empty(), then it implies that there is a function is_empty() on the type String. In the Foundation Types, the type String isn’t fully defined - it only contains functions needed by other parts of the specs. In more recent times, those needs have extended to Task Planning and Service Model.

This is to enable us to write specs that are fully defined. The Foundation types are assumed to be replaced in real implementations by types available in standard libraries, DBs, languages etc. So if in some language, the function for testing whether a String is empty is empty(), then you use that in all the places in the openEHR specs where you see is_empty() on a String property.

The same argument extends to everything in the Foundation Types. The Interval types you described are just the ones I created and used in the ADL Workbench - these were added years ago to the RM Support Model.

So there is no need for an implementation to use the exact Interval types defined in the Foundation Types - if there are different / better classes available in available libraries they may be used. However, in the case of Intervals, since they figure prominently in the AOM and serialised forms (ADL, JSON, XML etc) of archetypes, the serial form does need to be the same. We support single point cardinalities like {1} because UML supports them.

We could potentially add more of this explanation to the Foundation Types spec.