Missing information about temporal constraint validity constraints

There is an issue between C_DATE_TIME/C_DATE/C_TIME constraints serialized in ADL which include a "pattern" attribute to hold the values for the different xxx_validity fields of each AOM constraint (note the mismatch between the ADL and AOM representations, AOM doesn’t have a pattern).

UPDATE: tried to specify the timezone_validity (present in C_DATE, C_TIME and C_DATE_TIME) but the spec is not clear about how to do that in the current ADL ‘pattern’ way, for instance an optional timezone would be:

yyyy-mm-ddTHH:MM:SS.SSS+??:??

or

yyyy-mm-ddTHH:MM:SS.SSS-??:??

or other option?

This kind of representation of different constraints as a pattern format adds a lot of issues (see my last comment at the bottom), of course takes less bytes in the ADL but IMO it’s better to be clear than optimizing space.

a. There is no formal definition of those mappings between, e.g., pattern = yyyy-mm-ddTHH:MM:SS (ADL) and month_validity, day_validity, etc. We have only examples.

In AOM 1.4 the only comment is ‘??’ corresponds to VALIDITY_KIND.optional it doesn’t mention what should be considered VALIDITY_KIND.mandatory or VALIDITY_KIND.prohibited

See description of C_DATE: https://specifications.openehr.org/releases/AM/Release-2.2.0/AOM1.4.html#_c_date_class

The ADL spec also states only what is optional (https://specifications.openehr.org/releases/AM/Release-2.2.0/ADL1.4.html#_partial_datetimes ) and it’s not clear what should be considered mandatory and prohibited VALIDITY_KIND.

b. There is no mention of how to proceed in terms of data validation with datetimes that have timezone or decimal fractions like 2021-06-21T00:00:00,123-03:00, how is that validated against C_DATE_TIME.pattern = yyyy-mm-ddTHH:MM:SS that appears in the ADL? What would be the pattern for the xxx_validity including decimal fraction and timezone?

A comment/clarification about this, and maybe an example, would be good for the spec.

c. There is no mention of how to validate basic ISO 8601 format, for instance if the C_DATE_TIME.pattern = yyyy-mm-ddTHH:MM:SS in the ADL, being the basic DATE_TIME.value = 20210621000000,123-0300 in the data.

I guess by having the full mapping between the ADL pattern and the AOM xxx_validity fields of C_DATE, C_TIME and C_DATE_TIME, this item will be clear (point a).

I think ADL should have:

"For C_DATE_TIME, C_DATE and C_TIME constraint classes, when the constraint is about date/time field validity (month_validity, day_validity, etc), i.e. the constraint is not a range, then in ADL the constraint is serialized with a 'pattern' attribute, that is not part of the corresponding AOM classes, and represents all the values for the xxx_validity fields of the aforementioned constraint classes. This is just a design decision on how to encode all those xxx_validity fields in ADL, and the 'pattern' attribute doesn't represent a format or regular expression."

Then specify the mappings of each component of the pattern with each xxx_validity field in the AOM classes (this in the ADL spec).

Then in the AOM spec, clarify the pattern used in ADL is not constraining the format of the data:

"Neither C_DATE_TIME, C_DATE or C_TIME define any constraints over the specific format in which the DV_DATE_TIME, DV_DATE or DV_TIME instance data should have, those just need to be compliant with the ISO 8601 specification. That means both basic and extended formats are allowed, including timezones and decimal fraction for the time data. Consider the separator character for the decimal fraction could depend on the locale, in some languages it could be a period, in other languages it could be a comma. Implementations could decide on supporting both or just one depending on the locale of the runtime environment".

I know that last part goes over the scope of the AOM, but is something that should be mentioned somewhere, since we had several discussion about the decimal fraction separator

Note: I didn't review the AOM/ADL 2 specs, so don't know if this is an issue also there.

BTW, instead of this pattern IMO would be better to have explicit day_validity, month_validity, etc. attributes directly in the ADL, which is a direct mapping from ADL to AOM (maybe for ADL 2.x).