Mattias Forss wrote:
2006/5/22, Rong Chen <rong@acode.se <mailto:rong@acode.se>>:
Mattias Forss wrote:
> Hello,
>
> I'm wondering what is happening to the Java kernel at this moment.
> This list has been quite dead for the last couple of weeks... Rong,
> could you give a status report on your job? I haven't seen any
updates
> committed in quite some time. Have you gone away on some
business trip?
I will be on a trip from 24th of May to 4th of June.
Okay, then I doubt you have the time to do any coding until you come
back.
>
> Hope something happens soon, I would really appreciate if the
update
> of the kernel (especially the AM and ADL outputter) could progress a
> little faster. There are tons left to do (sorry if I'm being pushy).
I hope so too. What's on the top of your wish list?
I have included some previous and some new reports to you below. They
will be ordered in the priority I wish things to be implemented. From
a general point of view, I have prioritised the easy/small changes first.
If someone else is reading this, particularly someone related to the
Ocean editor, they should see point number 4. This shows that the
Ocean editor produces faulty coded text syntax when the code list is
empty. I also wrote some short concluding thoughts relating to the
openEHR project and kernel at the end of this letter.
1. Fix property and non-existing unit support in CDvQuantity
We have fixed this in the ADL workbench and the openEHR.org archetypes.
See
http://my.openehr.org/wsvn/oe_distrib/windows/adl_workbench/?op=dl&rev=0&isdir=1
and also the knowledge SVN server.
_________________________________________________________________________________________________________________
Yes, these properties are fixed now and archetypes are currently
having a property with an openEHR support terminology code instead. So
instead of the need to parse, say "Acceleration" in order to make a
DvCodedText with your service, you now only need to parse the string
"openEHR::339" and create a DvCodedText from that. However, it can be
a good idea to keep the parsing of a plain string property also to in
order to be a little backwards compatible... but I doubt Thomas would
agree since the specifications are meant to be followed at all times.
I have just realised that the published spec says DV_CODED_TEXT, but we
have implemented it as a CODE_PHRASE in the Eiffel software. This means
that in the test archetypes it has [openehr:xxx] in the relevant
location, because CODE_PHRASE is understood by dADL as a based type
(along with INTEGER, STRING etc). Doing DV_CODED_TEXT in the C_QUANTITY
means that the dADL gets quite a lot larger in archetypes - it has to be
something like:
property = <
value = <"acceleration">
defining_code = <
terminology_id = <
value = <"openehr">
>
code_string = <"1234">
>
>
whereas we just have
property = <[openehr::1234]>
There are two reasons to prefer CODE_PHRASE:
a) the dADL of a C_QUANTITY is much smaller (note that if we were using
XML the problem would be the same, but x 2) - there are a lot of
archetypes that would get quite a lot bigger if we have to have
DV_CODED_TEXT
b) the type in question (C_QUANTITY) is part of the archetype model, not
the reference model, and Sam felt it was reasonable for tool-builders to
be able to convert a CODE_PHRASE to a DV_CODED_TEXT in the tool GUI.
I think these reasons are sufficient to make C_QUANTITY.property a
CODE_PHRASE. Thoughts?
- thomas