Yep, I know 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. On Tue, Mar 20, 2018 at 5:10 PM, Pieter Bos <[email protected]> wrote: > 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 > > Op 20 mrt. 2018 om 21:06 heeft Pablo Pazos <[email protected]< > mailto:[email protected]>> het volgende geschreven: > > 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]< > mailto:[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]<mailto:openEHR- > [email protected]> > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > > > > -- > Ing. Pablo Pazos Gutiérrez > [email protected]<mailto:[email protected]> > +598 99 043 145 > skype: cabolabs > [https://docs.google.com/uc?export=download&id=0B27lX- > sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4 > VXBxWFZ6OXNnPQ] <http://cabolabs.com/> > http://www.cabolabs.com<http://www.cabolabs.com/> > https://cloudehrserver.com<https://cloudehrserver.com/> > Subscribe to our newsletter<http://eepurl.com/b_w_tj> > > _______________________________________________ > openEHR-technical mailing list > [email protected]<mailto:openEHR- > [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 > -- Ing. Pablo Pazos Gutiérrez [email protected] +598 99 043 145 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
