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
value matches {
ORDINAL matches {
value matches {
1|[local::at0006], -- Mild
4|[local::at0007], -- Moderate
7|[local::at0008] -- Severe
}
}
}
}
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
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
value matches {
ORDINAL matches {
value matches {1}
symbol matches {
CODED_TEXT matches {
defining_code matches {[local::at0006]} -- Mild
}
}
}
ORDINAL matches {
value matches {4}
symbol matches {
CODED_TEXT matches {
defining_code matches {[local::at0007]} -- Moderate
}
}
}
ORDINAL matches {
value matches {7}
symbol matches {
CODED_TEXT matches {
defining_code matches {[local::at0008]} -- Severe
}
}
}
}
}
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
value matches {
1|[local::at0006], -- Mild
4|[local::at0007], -- Moderate
7|[local::at0008] -- Severe
}
}
Please help me straighten out this issue.
Regards,
Mattias
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:
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