A Calendar datatype. Op 20 mrt. 2018 23:33 schreef "A Verhees" <[email protected]>:
> 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 > > Op 20 mrt. 2018 23:24 schreef "A Verhees" <[email protected]>: > >> 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. >> >> Op 20 mrt. 2018 23:08 schreef "A Verhees" <[email protected]>: >> >>> 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://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 >>> >>> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" <[email protected]>: >>> >>> 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 :) >>> >>> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On 19/03/2018 22:25, Pablo Pazos wrote: >>>> >>>> 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.* >>>> >>>> >>>> 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. >>>> >>>> >>>> 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. >>>> >>>> >>>> agree, we should do this - can you create a PR for this? Or add to an >>>> existing PR. >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> 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. >>>> >>>> >>>> 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 >>>> >>>> >>>> the page where you got that link >>>> <https://www.openehr.org/releases/RM/Release-1.0.3/docs/index> is now >>>> fixed. >>>> >>>> - thomas >>>> >>>> >>>> _______________________________________________ >>>> openEHR-technical mailing list >>>> [email protected] >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >>>> lists.openehr.org >>>> >>> >>> >>> >>> -- >>> Ing. Pablo Pazos Gutiérrez >>> [email protected] >>> +598 99 043 145 <+598%2099%20043%20145> >>> skype: cabolabs >>> <http://cabolabs.com/> >>> http://www.cabolabs.com >>> https://cloudehrserver.com >>> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> [email protected] >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >>> lists.openehr.org >>> >>> >>>
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
