# 2 months...
**URL:** https://discourse.openehr.org/t/2-months/14586
**Category:** Reference Implementation: Java (archive)
**Created:** [11 October 2006 11:05 UTC](https://discourse.openehr.org/t/2-months/14586 "2006-10-11T11:05:10Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@Mattias\_Forss1](https://discourse.openehr.org/u/Mattias_Forss1)
#### Post date: [11 October 2006 11:05 UTC](https://discourse.openehr.org/t/2-months/14586/1 "2006-10-11T11:05:10Z")
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
---
### Author:  [@rong.chen](https://discourse.openehr.org/u/rong.chen)
#### Post date: [11 October 2006 11:43 UTC](https://discourse.openehr.org/t/2-months/14586/2 "2006-10-11T11:43:16Z")
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](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](http://my.openehr.org/wsvn/ref_impl_java/?op=log&rev=0&sc=0&isdir=1)
Mattias Forss wrote:
---
### Author:  [@Mattias\_Forss1](https://discourse.openehr.org/u/Mattias_Forss1)
#### Post date: [11 October 2006 12:00 UTC](https://discourse.openehr.org/t/2-months/14586/3 "2006-10-11T12:00:59Z")
> 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
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [11 October 2006 15:30 UTC](https://discourse.openehr.org/t/2-months/14586/4 "2006-10-11T15:30:29Z")
> 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
---
### Author:  [@Mattias\_Forss1](https://discourse.openehr.org/u/Mattias_Forss1)
#### Post date: [11 October 2006 21:29 UTC](https://discourse.openehr.org/t/2-months/14586/5 "2006-10-11T21:29:16Z")
> \> 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
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [11 October 2006 21:57 UTC](https://discourse.openehr.org/t/2-months/14586/6 "2006-10-11T21:57:21Z")
> > 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
---
### Author:  [@rong.chen](https://discourse.openehr.org/u/rong.chen)
#### Post date: [12 October 2006 09:05 UTC](https://discourse.openehr.org/t/2-months/14586/7 "2006-10-12T09:05:25Z")
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
---
### Author:  [@Mattias\_Forss1](https://discourse.openehr.org/u/Mattias_Forss1)
#### Post date: [12 October 2006 09:19 UTC](https://discourse.openehr.org/t/2-months/14586/8 "2006-10-12T09:19:01Z")
Okay, but In order to fix this I also have to do one of the two
suggestions above?
/Mattias
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [12 October 2006 09:48 UTC](https://discourse.openehr.org/t/2-months/14586/9 "2006-10-12T09:48:44Z")
> 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
---
### Author:  [@Mattias\_Forss1](https://discourse.openehr.org/u/Mattias_Forss1)
#### Post date: [12 October 2006 10:02 UTC](https://discourse.openehr.org/t/2-months/14586/10 "2006-10-12T10:02:48Z")
> \> 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
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [15 October 2006 16:24 UTC](https://discourse.openehr.org/t/2-months/14586/11 "2006-10-15T16:24:53Z")
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\ (which the ADL shown
above will map to).
- thomas