In Java Reference Implementation, class
org.openehr.am.openehrprofile.datatypes.quantity.CDvOrdinal should
specifying constraints on instances of DV_ORDINAL.
Similarly org.openehr.am.openehrprofile.datatypes.quantity.CDvQuantity
represents constrain instances of DV_QUANTITY.
While CDvQuantity extends and uses DvQuantity class of RM model,
CDvOrdinal extends and uses Ordinal class of AOM model! Instead of
Ordinal class, I expected to have DvOrdinal, as indicated in AOM
specification too
(http://www.openehr.org/releases/1.0.2/architecture/am/openehr_archetype_profile.pdf
page 20).
I don't understand if this is an implementation bug, or if there are
some reasons to do this.
Hello Leonardo,
Here are the declarations of the classes you’ve mentioned:
public class CDvQuantity extends CDomainType
and
public class CDvOrdinal extends CDomainType
Now both of these clasesses descend from CDomainType, just like the specification says.However, the specification describes CDVOrdinal as a container of a list of "DV_Ordinal"s, and its implementation indeed seems to contain Ordinal instead.
There appears to be a mismatch indeed, so I too would kindly ask for further feedback about this.
Thanks for bringing this up. This issue has been brought up several
times in the past and lost in discussions (before we got JIRA that is
=) Now I finally logged it in the Jira.
A short answer to your question is that this is not a bug in the
implementation. It is a practical solution circumventing a minor
defect in the design. More details see http://www.openehr.org/issues/browse/SPEC-307
Both the Eiffel and the Java reference implementations have the same
solution here.
Thanks for the feedback Rong,
I had a piece of comment in my previous reply which I’ve deleted before sending it. It appears what I had in mind was partly true, having RM instances in AOM did not make sense actually. It introduces some sort of chicken-egg situation.
Thanks for your replies.
In my opinion the real problem is not using RM instances in AOM, but
having a not uniform management in AOM classes. Thare are a lots of
examples of RM classes used in AOM (e.g. DvQuantity).
If we have to use Ordinal because data types don't match, probably
specification are wrong or incomplete, and in this case a fix in
implementation cannot be the final solution.
Moreover, we have this problem:
- in archetype CDvOrdinal is a container of Ordinal
- when we parse data instances we find and use DvOrdinal data (RM
objects) and not Ordinal (AOM objects).
So during archetype validation, we need to perform an explicit cast
between DvOrdinal and Ordinal.
Maybe specifications should be extended to avoid having attribute
"value" as string, or maybe in implementation a cast between int and
string can be preformed.
Thanks for your replies.
In my opinion the real problem is not using RM instances in AOM, but
having a not uniform management in AOM classes. Thare are a lots of
examples of RM classes used in AOM (e.g. DvQuantity).
If we have to use Ordinal because data types don't match, probably
specification are wrong or incomplete, and in this case a fix in
implementation cannot be the final solution.
That's exactly the reason why the SPEC-307 was raised so the issue
would be dealt with in the future release of the specs.
Moreover, we have this problem:
- in archetype CDvOrdinal is a container of Ordinal
- when we parse data instances we find and use DvOrdinal data (RM
objects) and not Ordinal (AOM objects).
So during archetype validation, we need to perform an explicit cast
between DvOrdinal and Ordinal.
When working with archetypes (parsing, authoring etc), we don't have
sufficient data to create DvOrdinal instances therefore the cast is
impossible. It's only becomes possible at data entry point when the
string value is known.
Maybe specifications should be extended to avoid having attribute
"value" as string, or maybe in implementation a cast between int and
string can be preformed.
DvOrdinal is OK as is. We only need an intermediate object in AOM to
hold the integer value and the code phrase.