Thomas Beale wrote:
Rong Chen wrote:
Thomas Beale wrote:
Just to record a few previous emails in the list....
Hi all!
Our priority wish-list is as follows:
1. Fix the parser so it can parse the archetypes at openEHR homepage
Need to be more specific, e.g. what syntax in which archetype breaks the
parser; I would bet even we fix all of the following items, it will
still be problems with those archetypes.
Why should that be? They are ADL 1.3 compliant, which is what all
archetypes are now - I'm not sure what problems you foresee...
Maybe I was bit negative, but I would like to have more specific
requests on it. For me, the primary goal of the parser upgrade is to
support all the archetypes from the openEHR site, but we need to take
steps to be there.
I will update the project page today and list all the missing features
that could be implemented during this upgrade.
1.
2. Embedded dADL support in the parser (primarily to be able to
_parse_ archetypes containing embedded dADL without parse
errors. Object instansiation can wait)
Is this only the "[]" support, if so it should be a quick fix without
changes on the kernel.
1.
2. Support for instruction and its related parts in the AOM
1.
2. Support for action and its related parts in the AOM
It would be nice if the above things can be implemented within 3 weeks
in order not to stop the archetype editor development.
Requires update of the kernel - need more investigation to estimate the
work load, but the entry package seems quite different from the release
0.95. 
actually no update of the kernel is needed to make the parser parse 0.95
based archetypes - at least not in my Eiffel version - I don't
understand why it should be the case in the Java version...
I know the idea works for the RM part of the kernel. But the issue here
is that the AOM also got changed, e.g. ArchetypeDescription class, which
is also part of the java kernel. Since the parser use AOM for object
output as the parsing result, the parser is dependent on the AOM
classes, therefore the parser must be updated if the AOM changes.
Originally, the AOM and RM are bit separated so it was possible to have
a more 'generic' AOM module which can be used by the parser to handle
any type of RM, openEHR RM or CEN13606 RM. But it isn't quite true,
since the AOM contains some special classes, now known as openEHR
clinical profile classes, which reference the openEHR RM, it makes the
AOM module dependent on the openEHR RM. The ideal way of packaging would
be as following:
1. openEHR RM module
2. generic AOM module, no dependency on any RM modules - support any RM,
no dependency !
3. generic ADL parser, without support for openEHR clinical profile
shortcuts syntax - just support any generic ADL syntax, dependent on (2)
4. a separate package which contains AOM classes specific for openEHR
clinical profile classes, dependent on (1) (2)
5. a parser plug-in for the generic parser to support openEHR clinical
profile syntax, (1)
The benefits of such packaging is that: 1) no dependency from the parser
to the openEHR RM directly; 2) the openEHR RM (1) and the generic AOM
(2) / parser (3) can evolve without effecting each other. Presumably
after a while the AOM and ADL syntax will be more stable than the RM,
and the RM will continuously evolve by itself but without any impact on
the parser.
As it is now, we still can achieve by changing the packaging scheme a
bit. We just need to have finer module products then it is now. So
instead of having one big kernel as the product jar, we could have it
divided into smaller more coherent products/jars:
1. openehr-rm (with a version in the future maybe, e.g. openehr-rm-1.0,
openehr-rm-1.2, and both should work well with the parser)
2. openehr-aom
3. openehr-adl-paser
4. openehr-clinical-profile
5. openehr-clicnial-profile-adl-plugin
We probably should also split the adl-outputter, and rm-object-creation
logic from the kernel as well. Any thoughts or comments on this? Tom,
how is that done in your Eiffel parser and RM/AOM implementation?
Rong
