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 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
