# ADL/AOM 1.5 - proposed change to representation of date/time constraints

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2008-10-26 12:11 UTC
**Views:** 3
**Replies:** 0
**URL:** https://discourse.openehr.org/t/adl-aom-1-5-proposed-change-to-representation-of-date-time-constraints/12046

---

## Post #1 by @thomas.beale

Dear all,

in the current AOM spec ([http://www.openehr.org/releases/1.0.1/architecture/am/aom.pdf](http://www.openehr.org/releases/1.0.1/architecture/am/aom.pdf) section 6), the C_DATE class is defined as follows:

class C_DATE
month_validity[0..1]: VALIDITY_KIND
day_validity[0..1]: VALIDITY_KIND
timezone_validity[0..1]: VALIDITY_KIND
range[0..1]: Interval<Date>
assumed_value[0..1]: Date

class VALIDITY_KIND - enum with values mandatory, optional, disallowed

However, in the current XML-schema - [http://www.openehr.org/releases/1.0.1/its/XML-schema/documentation/Archetype.xsd.html#h-516027697](http://www.openehr.org/releases/1.0.1/its/XML-schema/documentation/Archetype.xsd.html#h-516027697) , the representation is:
<complexType name="C_DATE">
<complexContent>
<extension base=" [C_PRIMITIVE](http://www.openehr.org/releases/1.0.1/its/XML-schema/documentation/Archetype.xsd.html#h1279968838) ">
<sequence>
<element name="pattern" type=" [DateConstraintPattern](http://www.openehr.org/releases/1.0.1/its/XML-schema/documentation/Archetype.xsd.html#h-1253767808) " minOccurs="0"/>
<element name="timezone_validity" type=" [VALIDITY_KIND](http://www.openehr.org/releases/1.0.1/its/XML-schema/documentation/Archetype.xsd.html#h305506364) " minOccurs="0"/>
<element name="range" type=" [IntervalOfDate](http://www.openehr.org/releases/1.0.1/its/XML-schema/documentation/basetypes.xsd.html#h888547087) " minOccurs="0"/>
<element name="assumed_value" type=" [Iso8601Date](http://www.openehr.org/releases/1.0.1/its/XML-schema/documentation/basetypes.xsd.html#h652387245) " minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>

This is based on ADL, where the representation of any of the DATE, C_TIME, C_DATE_TIME, C_DURATION constraints is with either a pattern like YYYY-MM-?? or a range of values.

In the reference Eiffel parser, we also use only the following for C_DATE:
assumed_value: [like prototype_value] ISO8601_DATE
pattern: STRING
range: INTERVAL [ISO8601_DATE]

So, in ADL, the XML, and at least the reference parser, we simply use the ISO 8601-inspired pattern + range representation for constraint, rather than all these boolean xxx_validity flags. To make comparisons with an actual DATE, TIME etc, I would expect to implement a relatively hard-wired piece of code, but I doubt if I would use these flags. I am therefore wondering what implementers would think of simplifying the clases C_DATE, C_TIME, C_DATE_TIME, C_DURATION to conform more closely to the XML-schema and ADL way of representing the constraints. We could retain the boolean flags as functions if required. You can see from C_DATE_TIME and C_DURATION that this would simplify the AOM representation significantly. The other thing I prefer about using the patterns is that they are very ISO8601-like and I think more intuitive.

The C_DATE class in the AOM would become
class C_DATE
**pattern[0..1]: String**
range[0..1]: Interval<Date>
assumed_value[0..1]: Date
timezone_validity[0..1]: VALIDITY_KIND

I would also argue for a second change, which is to use the ISO8601 types like ISO8601_DATE (Iso8601Date in XML, Java, C# -speak) defined in the openEHR Support model, which would make the class look as follows:

class C_DATE
pattern[0..1]: String
range[0..1]: Interval<**Iso8601Date**>
assumed_value[0..1]: **Iso8601Date**
timezone_validity[0..1]: VALIDITY_KIND

Note that this proposal would not change the semantics of archetypes in anyway; it is only about representation in the software, and in fact, current software could remain as it is.

Would this change be desirable in the AOM?

- thomas beale

---


**Canonical:** https://discourse.openehr.org/t/adl-aom-1-5-proposed-change-to-representation-of-date-time-constraints/12046
**Original content:** https://discourse.openehr.org/t/adl-aom-1-5-proposed-change-to-representation-of-date-time-constraints/12046