# problem with ADL in sample archetype library

**URL:** <https://discourse.openehr.org/t/problem-with-adl-in-sample-archetype-library/14572>\
**Category:** Implementers (archive)\
**Created:** [24 September 2006 13:02 UTC](https://discourse.openehr.org/t/problem-with-adl-in-sample-archetype-library/14572 "2006-09-24T13:02:52Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Andrew\_Patterson](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/76d3ee/32.png) [@Andrew\_Patterson](https://discourse.openehr.org/u/Andrew_Patterson)\
**Post date:** [24 September 2006 13:02 UTC](https://discourse.openehr.org/t/problem-with-adl-in-sample-archetype-library/14572/1 "2006-09-24T13:02:52Z")

</div>

> From the sample archetype repository is this ADL construct

(its actually used in quite a few of the evaluation archetypes)

openEHR-EHR-EVALUATION.problem-diagnosis-histological.v1.adl

ELEMENT[at0005] occurrences matches {0..1} matches { -- Severity  
&nbsp;&nbsp;value matches {  
&nbsp;&nbsp;ORDINAL matches {  
&nbsp;&nbsp;&nbsp;&nbsp;value matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1|[local::at0006], -- Mild  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4|[local::at0007], -- Moderate  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7|[local::at0008] -- Severe  
&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;}  
&nbsp;&nbsp;}  
}

I don't know what format the 'value' list is in - its not a  
list of terms, or a list of integers or an interval. What ADL  
construct is it? Is it a legacy discontinued format, a future  
format, or have I just missed the section in the ADL doc  
(a distinct possibility!)

Andrew

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [24 September 2006 21:37 UTC](https://discourse.openehr.org/t/problem-with-adl-in-sample-archetype-library/14572/2 "2006-09-24T21:37:26Z")

</div>

Andrew,

Section 5 of  
[http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/am/openehr\_archetype\_profile.pdf](http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/am/openehr_archetype_profile.pdf)

- thomas

Andrew Patterson wrote:

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [24 September 2006 21:39 UTC](https://discourse.openehr.org/t/problem-with-adl-in-sample-archetype-library/14572/3 "2006-09-24T21:39:10Z")

</div>

This might help as well:  
[http://my.openehr.org/wsvn/ref\_impl\_eiffel/TRUNK/components/adl\_parser/src/syntax/cadl/parser/cadl\_validator.y?op=file&rev=0&sc=0](http://my.openehr.org/wsvn/ref_impl_eiffel/TRUNK/components/adl_parser/src/syntax/cadl/parser/cadl_validator.y?op=file&rev=0&sc=0)

- thomas

Andrew Patterson wrote:

---

<div class="post-metadata">

**Author:** ![Mattias\_Forss1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/m/e9c0ed/32.png) [@Mattias\_Forss1](https://discourse.openehr.org/u/Mattias_Forss1)\
**Post date:** [12 October 2006 08:07 UTC](https://discourse.openehr.org/t/problem-with-adl-in-sample-archetype-library/14572/4 "2006-10-12T08:07:04Z")

</div>

Hi Thomas,

I'm starting to doubt wheter the ADL example Andrew found below is  
correct. If you look at the specification it says that DV\_ORDINAL  
should have two attributes: symbol and value, where symbol is a  
DV\_CODED\_TEXT and value is an Integer. In the example the value  
attribute is a C\_DV\_ORDINAL which represents a set of constraints on  
instances of DV\_ORDINAL. The correct standard ADL would instead be:

ELEMENT[at0005] occurrences matches {0..1} matches { -- Severity  
&nbsp;&nbsp;&nbsp;&nbsp;value matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ORDINAL matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value matches {1}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;symbol matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CODED\_TEXT matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;defining\_code matches {[local::at0006]} -- Mild  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ORDINAL matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value matches {4}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;symbol matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CODED\_TEXT matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;defining\_code matches {[local::at0007]} -- Moderate  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ORDINAL matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value matches {7}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;symbol matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CODED\_TEXT matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;defining\_code matches {[local::at0008]} -- Severe  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;}  
}

But what I think we want to achieve here is to have the C\_DV\_ORDINAL  
by itself, i.e:

ELEMENT[at0005] occurrences matches {0..1} matches { -- Severity  
&nbsp;&nbsp;&nbsp;value matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1|[local::at0006], -- Mild  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4|[local::at0007], -- Moderate  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7|[local::at0008] -- Severe  
&nbsp;&nbsp;&nbsp;&nbsp;}  
}

Please help me straighten out this issue.

Regards,

Mattias

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [12 October 2006 10:17 UTC](https://discourse.openehr.org/t/problem-with-adl-in-sample-archetype-library/14572/5 "2006-10-12T10:17:48Z")

</div>

Mattias, Andrew,

You are correct - thanks for pointing this out. I have logged a report  
in the Archeype Editor Mantis instance. The correct example of C\_ORDINAL  
in the openEHR archetype repostory is by the way in the  
test/clinical\_types directory.

It will take a while before all these errors can be automatically  
prevented - it requires having a generic reference model checker built  
into the parser. The checker itself is not such a big deal, although it  
will certainly take some work; the problem has been how to get a usable  
expression of a reference model into it, without rewriting it from  
scratch. In theory we should have been able to use the XMI output of  
MagicDraw, the UML tool we use, but it is only 1.1, and contains many  
errors. We have analysed the output of a number of tools, and their  
representation of simple models is often just wrong (particularly to do  
with generic types and basic types), mainly because UML 2.0 is a  
disaster as a specification (what was needed was a simple object  
meta-model; what we got was a complicated dog's breakfast, as we say in  
English;-). We can't immediately upgrade to the version of MagicDraw  
that supports XMI 1.4 (or whatever the versoin for UML 2 is), because  
the vendor cunningly changed the publication tools, which we had to  
modify heavily to get any sensible web output (this isn't particularly  
the fault of the MagicDraw people; EA and many other tools generate  
nearly unreadable object models due to the slavish following of UML 2,  
and a lack of understanding about what developers need to see on the  
screen).

My plan here is to instead use model specifications in dADL, generated  
by some other means, and mapped to a far simpler XML form. Doing the  
tooling for this isn't that hard - part of it already exists (being able  
to read a dADL text in and turn it directly into objects; I have an  
implementation in Eiffel and I think Grahame Grieve has one in Java by now).

So, we have to recognise that there are real problems in UML 2.0 and the  
tools built on it, which prevent easy processing of object model  
schemas. Solutions will be found, but they will take time. It may well  
be in the Java space that we first solve this problem.

- thomas

Mattias Forss wrote:

---

<div class="post-metadata">

**Author:** ![Mattias\_Forss1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/m/e9c0ed/32.png) [@Mattias\_Forss1](https://discourse.openehr.org/u/Mattias_Forss1)\
**Post date:** [12 October 2006 12:41 UTC](https://discourse.openehr.org/t/problem-with-adl-in-sample-archetype-library/14572/6 "2006-10-12T12:41:01Z")

</div>

> Mattias, Andrew,
> 
> You are correct - thanks for pointing this out. I have logged a report  
> in the Archeype Editor Mantis instance. The correct example of C\_ORDINAL  
> in the openEHR archetype repostory is by the way in the  
> test/clinical\_types directory.

Okay, thanks

> It will take a while before all these errors can be automatically  
> prevented - it requires having a generic reference model checker built  
> into the parser. The checker itself is not such a big deal, although it  
> will certainly take some work; the problem has been how to get a usable  
> expression of a reference model into it, without rewriting it from  
> scratch. In theory we should have been able to use the XMI output of  
> MagicDraw, the UML tool we use, but it is only 1.1, and contains many  
> errors. We have analysed the output of a number of tools, and their  
> representation of simple models is often just wrong (particularly to do  
> with generic types and basic types), mainly because UML 2.0 is a  
> disaster as a specification (what was needed was a simple object  
> meta-model; what we got was a complicated dog's breakfast, as we say in  
> English;-). We can't immediately upgrade to the version of MagicDraw  
> that supports XMI 1.4 (or whatever the versoin for UML 2 is), because  
> the vendor cunningly changed the publication tools, which we had to  
> modify heavily to get any sensible web output (this isn't particularly  
> the fault of the MagicDraw people; EA and many other tools generate  
> nearly unreadable object models due to the slavish following of UML 2,  
> and a lack of understanding about what developers need to see on the  
> screen).
> 
> My plan here is to instead use model specifications in dADL, generated  
> by some other means, and mapped to a far simpler XML form. Doing the  
> tooling for this isn't that hard - part of it already exists (being able  
> to read a dADL text in and turn it directly into objects; I have an  
> implementation in Eiffel and I think Grahame Grieve has one in Java by now).
> 
> So, we have to recognise that there are real problems in UML 2.0 and the  
> tools built on it, which prevent easy processing of object model  
> schemas. Solutions will be found, but they will take time. It may well  
> be in the Java space that we first solve this problem.

Nobody has said that UML 2.0 is perfect for solving all problems.  
Maybe it's a good idea to resort to something far more simpler and  
your plan sounds like the best we can do for now. But who knows, in  
the future UML 3.0 might become a less complicated dog's breakfast 🙂

Mattias