A duration is an expression of the form PnYnMnDTnHnMnS, where each part is optional (years, months, etc.).
C_DURATION has constraints that allow or not each part/component, and also has a range constraint.
The range constraint has upper and lower limits that are of type Duration. If we have a range of P1M..P30M, does P1Y validate against that constraint or not?
Another case: range = P2Y..P5Y and value = P1Y20M, does that fail because 1Y < 2Y or passes because the 20M is calculated as 1Y? I have checked in Java it is possible to normalize certain durations so 20M becomes 1Y8M.
The question comes from: if the value should have the same components as the range and validate each component individually or if there are different components there is a unit conversion to do the comparison, like: range.contains(value).
Another question is: both range and allowed fields constraints could be mixed, so we could have:
allowed months = false
range P1M..P30M
Should the range be also compliant with the allowed fields? There is no rule in the spec AFAIK that checks that situation (Archetype Object Model 1.4 (AOM1.4))
If these cases are not considered in the current specs, we might need to clarify these cases, since it is related to conformance testing.
They support limiting the C_DURATION parts in a template as:
PWD/|P0W..P50W| -- 0-50 weeks, expressed only using weeks and days
I would skip using Y and M (years, months) since they don’t have a constant number of days and add ambiguity to the system. How many days is a M (28, 29, 30, 31)?
They can easily be replaced with W and D which are unambiguous.
Maybe specifications could advise against using Y and M?
I’m working in ADL1.4, the pattern is mapped to the xxx_allowed fields of C_DURATION in ADL 1.4. Maybe you need another thread to tackle the issues of ADL 2.
The issues you face are based on the underlying technology, like using Java Duration vs. Period types. In ISO 8601 using years and months is perfectly fine, and works well when referring to durations in those units, though you can’t just get stuff like seconds in a year or in a month. For instance, it is not ambiguous to say a pregnancy has a duration of 5 months, it doesn’t matter how many days exactly that amount is, so the issue is about precision not about ambiguity IMHO. Though this could be difficult to implement when dealing with a concrete programming language because the notion of precision should be present and current Java types might not have it. Sometimes we can’t rely on native types and we need to create our own to support the semantics we need.
But we are talking about different things, my question is about how to evaluate the constraints, and your question is about the representation of a duration.
Just a quick one for now - healthcare professionals regularly use years and months, as well as weeks, days etc, e.g in obstetrics and elsewhere in general medicine. Obstetricians, midwives etc are not worried about that fact that the length of months or years is slightly variable.
To enable some (approximate, but good enough) computing to be done, we just use average month and year lengths, defined in the time classes.
Thank you for this explanation. I have missed the “Time_Definitions” and its “average…” constants.
I’ve added them to my years/months => days formula.