Dear all,
in the current AOM spec (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
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 , the representation is:
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
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