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?
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.
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.
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.
> 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!
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.
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
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.
> 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?
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).
