ADL/AOM 1.5 - id-codes unification - the final change

Diego Boscá yampeku at
Thu Jan 2 04:41:09 EST 2014

Made a comment on the wiki page, but I will copy that here too:

Still thinking about this, but I have a first doubt:

What is the result of generating the standard equivalent ADL for this ADL
code? (from the example)

ELEMENT[id31] occurrences matches {0..1} matches {
                                        value matches {
                                            DV_CODED_TEXT[id5002] matches {
                                                defining_code matches {
                                                    at31,     -- Naked
                                                    at32,     --
Reduced clothing/bedding
                                                    at33,     --
Appropriate clothing/bedding
                                                    at34;     --
Increased clothing/bedding
                                                    at0033]    -- Assumed

Do atxx codes get changed to id codes magically or just new idxx are
generated? new idxx codes or id500x ones? new objects added to the 1.5
archetype should always have id50xx?

I'm still wondering if the at000N => idN+1 rule and the id5000 rule are a
good idea. I see a lot of potential problems and not much benefits:

I don't really think that keeping a at->id correspondence is a critical
issue: The user defining archetypes shouldn't even be aware of the changes,
and if we want reuse current systems, things like AQL paths should still
had to be rewritten to deal with the missing atxx codes, so not much
benefit of having a rule for direct translation.

My suggestion is to keep things as simple as possible and just put idxx
codes where needed. Maybe it's a good idea to use the at000N => idN+1 rule,
but for the missing ones I would just make another pass and put new idxx
codes starting from the last idxx code we assigned on the first pass. As
the 1.4 to 1.5 process only has to be done once, I think it's better to
make two passes to the original archetype and just put new idxx codes from
now on.

I'm not a fan of having different ranges of id with different meanings.
With templates being archetypes I won't discard having idxxxx with values
dangerously near to 5000...

2014/1/1 Thomas Beale <thomas.beale at>

> happy new year and best wishes for 2014. I hope your new year's day is a
> bright one (unless you live in the UK, in which case it's a lost cause
> today ;-)
> I have been working in the last few months to produce a final version of
> ADL/AOM 1.5, based on:
>    - existing requirements<>,
>    - emerging requirements - Intermountain, CIMI,
>    - Harold Solbrig's proposals for terms-as-URIs,
>    - Dave Carlson's MDHT
>    <>/ AML work
>    at OMG <>led by Robert
>    lario,
>    - general feedback on this list, particularly from David Moner's group
>    at UPV, where they have implemented different rules
>    - implementer feedback
> I have cc:d some relevant people who are not on this list - they might
> want to consider joining<>.
> If not, please email me and I'll post any views you have on the list, or
> else feel free to feedback on the wiki page below.
> So here's the proposal. To date, We have been trying to keep ADL/AOM 1.5
> backwardly compatible at the syntax level for ADL 1.4. However, I think
> this keeps too many old problems unsolved. I propose a new approach:
>    - make the central ADL/AOM 1.5 specifications as clean as possible
>    - provide a series of updates to ADL 1.4, coming from the 1.5 specs,
>    that are carefully designed to be applied to 1.4 tools, to bring them up to
>    date
>       - e.g. things like how to post-fit the new identifiers, tuple
>       support, annotations, to DAL 1.4 archetype tools
>        - provide rules and tooling to deal with differences between
>    archetype paths, upon which querying is based
>    - provide a 1.4 => 1.5 upgrade tool to completely convert existing ADL
>    1.4 archetypes to the new format
> The latest changes I propose (and have in fact implemented) are primarily
> about dealing properly with the long-running problem(s) of archetype node
> ids.
> It's documented here on the wiki<>
> .
> All comments and criticism welcome. If you think the proposal is broken in
> some way, or could be done better, don't be afraid to say so. Please
> comment on this list, or for substantive comments, the wiki page is
> probably better. Let's try and get to a final proposal that works for all
> ADL/AOM users - not just openEHR. I think that would be a real achievement.
> thanks
> - thomas
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-technical mailing list