# Should Duration class used in AOM 1.0.2 be ISO8601\_DURATION from support specs?
**URL:** https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512
**Category:** Technical (archive)
**Created:** [19 March 2018 05:24 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512 "2018-03-19T05:24:05Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [19 March 2018 05:24 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/1 "2018-03-19T05:24:05Z")
Hi,
Looking at CDuration [http://www.openehr.org/releases/1.0.2/architecture/am/aom.pdf](http://www.openehr.org/releases/1.0.2/architecture/am/aom.pdf) page 46, the range constraint is defined with a Duration class.
On the support specs [http://www.openehr.org/releases/1.0.2/architecture/rm/support\_im.pdf](http://www.openehr.org/releases/1.0.2/architecture/rm/support_im.pdf) page 30 we have the ISO8601\_DURATION class.
Should AOM reference that class or we have another Duration class somewhere?
Or should we use DV\_DURATION in CDuration? (DV\_DURATION inherits from ISO8601\_DURATION). [http://www.openehr.org/releases/1.0.2/architecture/rm/data\_types\_im.pdf](http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf) page 54
Thanks!
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [19 March 2018 08:57 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/2 "2018-03-19T08:57:06Z")
Again my thoughts
Duration is not a Data Type in many computer languages.
So we need to model it in an Archetype (Chairos)
Gerard Freriks
+31 620347088
[gfrer@luna.nl](mailto:gfrer@luna.nl)
Kattensingel 20
2801 CA Gouda
the Netherlands
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [19 March 2018 14:55 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/3 "2018-03-19T14:55:42Z")
Hi Gerard, this is about the current specs, not about what is supported by programming languages.
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [19 March 2018 15:13 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/4 "2018-03-19T15:13:48Z")
Hi Pablo,
you should use the specs on the [main spec home page](http://www.openehr.org/programs/specification/workingbaseline); in this case I guess it is the [AOM 1.4 spec](http://www.openehr.org/releases/AM/latest/docs/AOM1.4/AOM1.4.html#_primitive_package) you want to refer to.
We now have the basic time types in the [Foundation types spec](http://www.openehr.org/releases/BASE/latest/docs/foundation_types/foundation_types.html#_time_types). Both Duration and Iso8601\_Duration are defined. For the archetype spec, the former is assumed, because ISO8601 syntax representation is used in archetypes.
The specification is much better (but different) in [AOM2](http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_c_duration_class).
- thomas
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [19 March 2018 15:16 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/5 "2018-03-19T15:16:15Z")
that's true, but in databases and XML it is, and it is mostly treated like a primitive data type - i.e. a non-identified, instance-only type - in most language libraries. Note - here I am talking about a primitive type 'Duration' (also Iso8601\_duration), not types like DV\_DURATION. For AOM2, we treat it and the other date/time primitives as proper primitive types, also Uri, etc, and it makes life much easier.
- thomas
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [19 March 2018 16:25 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/6 "2018-03-19T16:25:25Z")
Duration must be modelled using Archetype and not as part of the RM or AOM.
Gerard Freriks
+31 620347088
[gfrer@luna.nl](mailto:gfrer@luna.nl)
Kattensingel 20
2801 CA Gouda
the Netherlands
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [19 March 2018 16:42 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/7 "2018-03-19T16:42:26Z")
My opinions:
First: I agree with the distinction in datatypes between AOM and RM. The AOM should live as much as possible independent from the RM (I prefer completely independent), the RM should only deal with data-constructions and datatypes to describe target-data in.
Second: The archetype should be independent from the used computer language to build the AOM in. In many languages Duration is a valid datatype.
Java has it, Golang has it, C++ has it. And if it is not in a programming language, that language should be extended by a library which delivers the datatype.
Best regards
Bert
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [19 March 2018 18:33 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/8 "2018-03-19T18:33:37Z")
Thanks Thomas, I see the Duration class on the baseline BASE model
[http://openehr.org/releases/BASE/latest/docs/foundation\_types/foundation\_types.html#\_overview\_5](http://openehr.org/releases/BASE/latest/docs/foundation_types/foundation_types.html#_overview_5)
But I’m a 1.0.2 implementer and I guess there are others. As far as I can see, there is no Duration class for 1.0.2. I would be good to add a disclaimer or errata comment for 1.0.2 maybe guiding to use ISO8601\_DURATION or DV\_DURATION in CDuration.
IMO that can generate a mismatch between implementations. For instance, the Java Ref uses DV\_DURATION in CDuration [https://github.com/wware/openehr-java/blob/master/openehr-aom/src/main/java/org/openehr/am/archetype/constraintmodel/primitive/CDuration.java#L186](https://github.com/wware/openehr-java/blob/master/openehr-aom/src/main/java/org/openehr/am/archetype/constraintmodel/primitive/CDuration.java#L186)
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [19 March 2018 19:03 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/9 "2018-03-19T19:03:26Z")
DV\_DURATION has never been the target type of C\_DURATION - DV\_DURATION is a complex type in the DV\_ORDERED hierarchy (i.e. a sibling more or less of DV\_QUANTITY). I don’t know why they do that - that is not what the spec says. - thomas
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [19 March 2018 19:05 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/10 "2018-03-19T19:05:24Z")
a cleaner programmer journey would be AOM2/ADL2, even if you stick to RM 1.0.2 😉
- thomas
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [19 March 2018 20:25 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/11 "2018-03-19T20:25:27Z")
Hi Thomas, the definition of DV\_DURATION is clear to me 🙂
The issue is on the 1.0.2 specs, I guess they used DV\_DURATION in C\_DURATION because the referenced Duration class in C\_DURATION was not included on the specs. This is the issue I’m pointing to, the missing class.
Clarifying that on an errata addendum would help to avoid such implementation mistakes, that are really caused by the missing information on the spec + interpretation to fill the gap.
BTW, this is one case that I detected because I’m doing research for a new course. There might be issues like this on other areas of 1.0.2, I mean missing classes referenced from AOM or AOP. I didn’t do a complete review of the specs.
I would love to migrate everything to baseline spec and use AOM2, but I can’t afford the cost right now. I’m sure others are on my same position.
BTW tried to check if the issue is also on 1.0.3 but the link to support is broken [http://openehr.org/RM/Release-1.0.3/support.html](http://openehr.org/RM/Release-1.0.3/support.html)
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [20 March 2018 10:21 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/12 "2018-03-20T10:21:51Z")
Right - the ADL/AOM 1.4 specs made the assumption that each primitive constrainer type i.e. C\_INTEGER, C\_STRING, C\_DATE, C\_DURATION etc, constrained a same- or similarly named primitive type like Integer, String, Date, Duration etc that are assumed to be part of the technology environment. THey are normally part of the programming language, DB, or serialisation formalisms. I think this probably was not as clear as it should have been in that spec. In the AOM2/ADL2 specs, we have clarified this so that the same types (C\_INTEGER etc) now refer to types that are defined in the Foundation spec of the BASE component. agree, we should do this - can you create a PR for this? Or add to an existing PR. hopefully that will change soon, because ADL2 is more regular and simpler than ADL1.4 - the ADL2 OPT for example is much easier to process. I’d be interested to know what the real costs are and to see what we can do to make the transition simpler, because staying with ADL1.4 is limiting system functionality for the future. the is now fixed. - thomas
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [20 March 2018 20:05 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/13 "2018-03-20T20:05:37Z")
Thanks Thomas, will create the PR!
Also will double check if the same happens with other types, but I think the only “odd” one that might not be correct to assume, is the Duration. For instance, Java 8 added the Duration as a base type, but it only handles day to seconds duration expressions, year, month, week are not supported. Each technology has it’s own quirks 🙂
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [20 March 2018 20:10 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/14 "2018-03-20T20:10:28Z")
Java 8 has a Duration for hours, minutes and seconds, and Period for years, months and days. Both implement a few interfaces with which you can abstract them.
No idea why they chose this, it’s quite annoying to work with. You can relatively easily implement your own variant of ChronoPeriof that supports all of the options.
Regards,
Pieter Bos
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [20 March 2018 20:54 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/15 "2018-03-20T20:54:13Z")
Yep, I know [https://docs.oracle.com/javase/tutorial/datetime/iso/period.html](https://docs.oracle.com/javase/tutorial/datetime/iso/period.html)
But this is not about anything Java specific, just giving an example why Duration might not be good for an assumed type on the openEHR specs 🙂
On the other hand… (re)thinking: assumed types should not be considered as “supported by a programming language”, but “supported by a programming language or application” \*\*\*. For instance, it is not so difficult to create a Duration class ourselves on any programming language, or even use one of the many available libraries that deal with Duration types and are compatible with ISO8601 durations.
Considering that, we might need to clarify:
1. What “assumed type” really is (it seems most tend to think that should be supported by a programming language, need to double check the specs to see how this is defined, maybe is clearly defined but not highlighted enough).
2. Clarify the use of the Duration class from CDuration where Duration is not on the specs (we can say it is assumed considering assumed as the definition \*\*\*)
3. Complementing 2. we can propose support for Duration on many programming languages by recommending certain libraries or core types. This can be an ITS or just an addendum/errata to v1.0.2 specs.
I think those points will solve all the issues mentioned on this thread.
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [20 March 2018 22:08 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/16 "2018-03-20T22:08:44Z")
Now you say, you are right.
The Java 8 duration is indeed diffrent, but you can still use the Joda duration, or you can write your own duration class. In Golang the duration class is also limited, it is build around nanoseconds, but I wrote my own which is conform the OpenEhr specs, which was not that hard.
[https://golang.org/pkg/time/#Duration](https://golang.org/pkg/time/#Duration)
[https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html](https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html)
Maybe it is a good idea for the OpenEhr community to study the duration type again to see why in two major programming languages there is another approach build around nanoseconds and having conversions to hours, etc. Maybe there is another trend coming up. Maybe it is interesting to conform to these trends
Bert
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [20 March 2018 22:24 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/17 "2018-03-20T22:24:32Z")
Now I come to think about it, I remember reading somewhere that conversion durations to number of years or months is no longer desired because years and months do not have always the same number of nanoseconds.
Of course conversions to days and weeks is easy, although they are also not always the same, but that can be ignored, it is one second every few years.
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [20 March 2018 22:27 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/18 "2018-03-20T22:27:03Z")
We can revisit all the types we want, but we shouldn’t forget that types will be used for medical data, and maybe we don’t really need nanosecond precision.
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [20 March 2018 22:33 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/19 "2018-03-20T22:33:45Z")
One last remark.
There is in medical context need of a datatypes to express: “do this one time a month, for example on a specific date”.
But technically seen, this is not a duration, the maybe a need for another datatype to express this.
Using the duration for this may be a handy shortcut in specs, but it is not right. It is in fact misusing a datatype which does not support this expression. The ISO string should also be changed accordingly.
Bert
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [20 March 2018 22:35 UTC](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512/20 "2018-03-20T22:35:54Z")
Nanoseconds are probably not needed many times in medical context, but they are not in the way of using them as seconds or minutes.
[Next page](https://discourse.openehr.org/t/should-duration-class-used-in-aom-1-0-2-be-iso8601-duration-from-support-specs/15512.md?page=2)