# 2 months... **Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154) **Created:** 2006-10-11 11:05 UTC **Views:** 10 **Replies:** 10 **URL:** https://discourse.openehr.org/t/2-months/14586 --- ## Post #1 by @Mattias_Forss1 Hi all, Today is exactly 2 months since something was committed on the ref\_impl\_java trunk\. It troubles me that nothing has happened since then\. I've been waiting for a long time to see support for action and instruction archetypes and archetype slots but nothing seem to happen\. Projects which haven't had any updates in two months can be thought of as dead in the open source world\. I don't want that to happen\! Isn't it possible to allocate some resources from UCL to be responsible for upgrading the reference implementation to follow version 1\.0\.1 of the openEHR specifications? I'm just hoping to see some action soon\.\. Mattias --- ## Post #2 by @rong.chen Hi Mattias, Actually, lots of commits happened on the sandbox branch recently\. We are still in the process of releasing more components that are based on updated 1\.0\.1 RM\. The last missing piece is the parser\. After the parser is fixed, all components will be lifted to the release\-1\.0\.1 branch\. Cheers, Rong $ svn ls http://svn.openehr.org/ref_impl_java/BRANCHES/sandbox adl\-serializer/ openehr\-aom/ openehr\-ap/ openehr\-dao/ openehr\-rm/ Check this for the change log http://my.openehr.org/wsvn/ref_impl_java/?op=log&rev=0&sc=0&isdir=1 Mattias Forss wrote: --- ## Post #3 by @Mattias_Forss1 > Hi Mattias, > > Actually, lots of commits happened on the sandbox branch recently\. We > are still in the process of releasing more components that are based on > updated 1\.0\.1 RM\. The last missing piece is the parser\. After the parser > is fixed, all components will be lifted to the release\-1\.0\.1 branch\. Hi Rong, I don't see any major changes in the AOM\.\.\. the only large changes I can see \(except the RM\) is the separation of the different parts of the kernel\. The serializer should also be fixed when the parser is fixed, since those two components have to be synched for round\-trip correctness\. Mattias --- ## Post #4 by @system > 2006/10/11, Rong Chen <[rong@acode.se](mailto:rong@acode.se)>: > > Hi Mattias, > > > > Actually, lots of commits happened on the sandbox branch recently. We > > are still in the process of releasing more components that are based on > > updated 1.0.1 RM. The last missing piece is the parser. After the parser > > is fixed, all components will be lifted to the release-1.0.1 branch. > > Hi Rong, > > I don't see any major changes in the AOM... the only large changes I That's because there are no big changes in the AOM. The assertion package is being implemented (at time of writing :) > can see (except the RM) is the separation of the different parts of The separation is necessary and a big step forward I believe. It facilitates reuse and testing of the components. Also it reduces the complexity of individual component and makes it easier for new developers to make contributions. > the kernel. The serializer should also be fixed when the parser is The serializer is already running on the 1.0.1 RM. The output of archetype description need some fix. If someone would like to offer some help to speed up the development, it's more than welcome! > fixed, since those two components have to be synched for round-trip > correctness. Exactly! The round-trip correctness is crucial. Rong @TheWorldOfHealthIT-Geneva --- ## Post #5 by @Mattias_Forss1 > > I don't see any major changes in the AOM\.\.\. the only large changes I > > That's because there are no big changes in the AOM\. The assertion package is > being implemented \(at time of writing :\) I think the assertion package is a major update and very crucial to my work\. Are there any other things except the assertion package, the parser and the serializer that need to be fixed before the reference implementation fully supports action and instruction archetypes? I hope that there aren't that much left, because I'd be very happy when I can start implementing the archetype editor in a more holistic way again :\-\) > > can see \(except the RM\) is the separation of the different parts of > > The separation is necessary and a big step forward I believe\. It facilitates > reuse and testing of the components\. Also it reduces the complexity of > individual component and makes it easier for new developers to make > contributions\. Yes I know that, and I think it's good that it has been done, but the separation was lower in my priority list :\-\) > > > the kernel\. The serializer should also be fixed when the parser is > > The serializer is already running on the 1\.0\.1 RM\. The output of archetype > description need some fix\. If someone would like to offer some help to speed > up the development, it's more than welcome\! I'd be very happy to help you fix the output of the archetype description\. Just tell me what needs fixing and I'll fix it tomorrow\! Cheers Mattias --- ## Post #6 by @system >> the development, it's more than welcome\! >>     > I'd be very happy to help you fix the output of the archetype > description\. Just tell me what needs fixing and I'll fix it tomorrow\! >   If Rong does not reply in a day or so, I can give you a hint about what I have found in adl\.jj and is related with what you discuss\. The classes Archetypedescription\(\-Item\) have been replaced by resourcedescription\(\-Item\)\. Also the parameters are changed, not much, but still\. The adl\.jj needs to be changed to reflect these rm\-changes\. If you take a look at the serializer, there you find a fixme in the method which writes the resourcedesription, there is a small thing to do, I forgot what exactly In any case, these are a few things that need to be done, so if you want to work, you know where to look\. Maybe there is more to do, I think Rong will surely tell you when he reads his email\. regards Bert Verhees --- ## Post #7 by @rong.chen Bert Verhees wrote: >>> the development, it's more than welcome\! >>>     >> >> I'd be very happy to help you fix the output of the archetype >> description\. Just tell me what needs fixing and I'll fix it tomorrow\! >>   > > If Rong does not reply in a day or so, I can give you a hint about what > I have found in adl\.jj and is related with what you discuss\. >   Bert, thanks for help outing here\. :\-\) > The classes Archetypedescription\(\-Item\) have been replaced by > resourcedescription\(\-Item\)\. > Also the parameters are changed, not much, but still\. The adl\.jj needs > to be changed to reflect these rm\-changes\. >   That's right\! What's tricky here is how to provide an instance of TerminologyService to be able to create ResourceDescriptionItem\. So far the alternatives are 1\) implement an simple terminology service that provides the minimum set of terminologies for the kernel to work properly\. it probably should be stand\-alone component 2\) adjust the spec a bit so that there is not need to provide terminologyService during the parsing phase since this is really the first time that parser needs to deal with terminologyService and it's probably could be avoided\. > If you take a look at the serializer, there you find a fixme in the > method which writes the resourcedesription, there is a small thing to > do, I forgot what exactly >   That's the thing needs to be fixed\. Cheers, Rong --- ## Post #8 by @Mattias_Forss1 Okay, but In order to fix this I also have to do one of the two suggestions above? /Mattias --- ## Post #9 by @system > 2006/10/12, Rong Chen <[rong@acode.se](mailto:rong@acode.se)>: > > > The classes Archetypedescription(-Item) have been replaced by > > > resourcedescription(-Item). > > > Also the parameters are changed, not much, but still. The adl.jj needs > > > to be changed to reflect these rm-changes. > > > > > > > That's right! What's tricky here is how to provide an instance of > > TerminologyService to be able to create ResourceDescriptionItem. So far > > the alternatives are 1) implement an simple terminology service that > > provides the minimum set of terminologies for the kernel to work > > properly. it probably should be stand-alone component 2) adjust the spec > > a bit so that there is not need to provide terminologyService during the > > parsing phase since this is really the first time that parser needs to > > deal with terminologyService and it's probably could be avoided. > > > > > If you take a look at the serializer, there you find a fixme in the > > > method which writes the resourcedesription, there is a small thing to > > > do, I forgot what exactly > > > > > That's the thing needs to be fixed. > > Okay, but In order to fix this I also have to do one of the two > suggestions above? No, this fix is in the serializer. The above suggestions are in the parser. Cheers, Rong --- ## Post #10 by @Mattias_Forss1 > > Okay, but In order to fix this I also have to do one of the two > > suggestions above? > > No, this fix is in the serializer\. The above suggestions are in the parser\. Thanks\. Will look into that\. By the way, should we print a language section instead of printing the language in the details? I just looked through the ADL spec and couldn't find the language attribute inside details\. It seems unneccesary to do this:   details = <     \["sv"\] = <       language = <"sv"> But its the way both editors currently outputs archetype description details\. I guess the current archetypes are wrong concerning they all have a missing language section? Mattias --- ## Post #11 by @thomas.beale Mattias Forss wrote: >   >>> Okay, but In order to fix this I also have to do one of the two >>> suggestions above? >>>       >> >> No, this fix is in the serializer\. The above suggestions are in the parser\. >>     > Thanks\. Will look into that\. > > By the way, should we print a language section instead of printing the > language in the details? I just looked through the ADL spec and > couldn't find the language attribute inside details\. It seems > unneccesary to do this: > >   details = < >     \["sv"\] = < >       language = <"sv"> > > But its the way both editors currently outputs archetype description > details\. I guess the current archetypes are wrong concerning they all > have a missing language section? > you will find the correct semantics in the Resource package classes in the Common IM\. The reason it is repeated is because the \["sv"\] can be mapped to a Hash table key in some implementations, but might not be in all, so we decided to put the language in the object as well, in case the implementter was forced to use just a List<T> \(which the ADL shown above will map to\)\. \- thomas --- **Canonical:** https://discourse.openehr.org/t/2-months/14586 **Original content:** https://discourse.openehr.org/t/2-months/14586