That is true, but I think it would be good if it would find its way in the RM, for two reasons 1) misusing the duration does not seem right, and I think the ISO string representing a duration must change. That is, I know, a long way, so the part before the 'T' should represent a calendar datatype, and the other part should be a duration. It is also worth considering to split the DV_DURATION type in the same way. 2) If it find its formal way in the RM libraries will support it also, which will help implementers to do it the right way.
Bert Op 20 mrt. 2018 23:48 schreef "Diego Boscá" <yamp...@gmail.com>: > Nothing restricts you to create a "data type pattern"/specialized cluster > that has exactly this semantics > > El mar., 20 mar. 2018 23:34, A Verhees <bert.verh...@rosa.nl> escribió: > >> 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" <bert.verh...@rosa.nl>: >> >>> 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" <bert.verh...@rosa.nl>: >>> >>>> 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" <pablo.pa...@cabolabs.com>: >>>> >>>> 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 <thomas.be...@openehr.org >>>> > 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 >>>>> openEHR-technical@lists.openehr.org >>>>> http://lists.openehr.org/mailman/listinfo/openehr- >>>>> technical_lists.openehr.org >>>>> >>>> >>>> >>>> >>>> -- >>>> Ing. Pablo Pazos Gutiérrez >>>> pablo.pa...@cabolabs.com >>>> +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 >>>> openEHR-technical@lists.openehr.org >>>> http://lists.openehr.org/mailman/listinfo/openehr- >>>> technical_lists.openehr.org >>>> >>>> >>>> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr- >> technical_lists.openehr.org > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
