Nanoseconds are probably not needed many times in medical context, but they are not in the way of using them as seconds or minutes.
Op 20 mrt. 2018 23:27 schreef "Diego Boscá" <[email protected]>: > 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. > > El mar., 20 mar. 2018 23:09, A Verhees <[email protected]> escribió: > >> 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 > > > _______________________________________________ > 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
