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
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,