Hi Thomas,
Is there any specific reason that the attribute list from C_DV_ORDINAL
has to be Set? I wonder if List would be better since it's good to keep
the the order of member element in the list.
Secondly, should the member be Ordinal or DvOrdinal. I found it is
difficult to create DvOrdinal directly in the parser. It was Ordinal in
the previous specification and your Eiffel code.
Regards,
Rong
Rong Chen wrote:
Hi Thomas,
Is there any specific reason that the attribute list from C_DV_ORDINAL
has to be Set? I wonder if List would be better since it's good to keep
the the order of member element in the list.
the main semantic requirement is for uniqueness (you can't have two
items in an ordinal set called '2' or '+++' etc); ordering is useful of
course, and most practical implementations are likely to have ordered
sets anyway. It isn't specified that way because in UML there is only
Set<T> and List<T>, and it is not clear how to say you want an ordered
set in the text (in the diagram you can put "{ordered}" on the line).
Secondly, should the member be Ordinal or DvOrdinal. I found it is
difficult to create DvOrdinal directly in the parser. It was Ordinal in
the previous specification and your Eiffel code.
the spec is self-consistent, but you are right in my code I still have
C_ORDINAL and ORDINAL. This was originally to make people interested in
CEN EN13606 feel better that no "openEHR" data types were in the
archetype model (which is now part 2 of EN13606), but I no longer see
this as a priority. openEHR has a more coherent set of data types than
any other standard or specification anyway, and I now believe coherence
and engineering quality to be more important. They aren't perfect of
course, but at this stage they seem to be pretty implementable and to work.
For practical purposes, you should feel free to deviate here as I have
done (I should fix it, but it won't make any difference one way or the
other anyway). All that it means is that if you use C_ORDINAL, in the
kernel there needs to be a way to use it to check a DV_ORDINAL instance
(rather than just an ORDINAL).
- thomas
Rong Chen wrote:
Hi Thomas,
Is there any specific reason that the attribute list from C_DV_ORDINAL
has to be Set? I wonder if List would be better since it's good to keep
the the order of member element in the list.Secondly, should the member be Ordinal or DvOrdinal. I found it is
difficult to create DvOrdinal directly in the parser. It was Ordinal in
the previous specification and your Eiffel code.Regards,
Rong
_______________________________________________
Ref_impl_java mailing list
Ref_impl_java@openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/ref_impl_java
I have uploaded a fixed version of this spec, also included some other
fixes for errors I spotted. I also included the proposed class
remodelling for State machine. This spec is still of course part of the
Release 1.0.1 candidate, so feel free to provide further feedback -
changes can still be made.
- thomas
Thomas Beale wrote:
Rong Chen wrote:
Hi Thomas,
Is there any specific reason that the attribute list from C_DV_ORDINAL
has to be Set? I wonder if List would be better since it's good to keep
the the order of member element in the list.
the main semantic requirement is for uniqueness (you can't have two
items in an ordinal set called '2' or '+++' etc); ordering is useful of
course, and most practical implementations are likely to have ordered
sets anyway. It isn't specified that way because in UML there is only
Set<T> and List<T>, and it is not clear how to say you want an ordered
set in the text (in the diagram you can put "{ordered}" on the line).
Yes, ordered set is most convenient. But perhaps it can be further
specified in ITS.
Secondly, should the member be Ordinal or DvOrdinal. I found it is
difficult to create DvOrdinal directly in the parser. It was Ordinal in
the previous specification and your Eiffel code.
the spec is self-consistent, but you are right in my code I still have
C_ORDINAL and ORDINAL. This was originally to make people interested in
CEN EN13606 feel better that no "openEHR" data types were in the
archetype model (which is now part 2 of EN13606), but I no longer see
this as a priority. openEHR has a more coherent set of data types than
any other standard or specification anyway, and I now believe coherence
and engineering quality to be more important. They aren't perfect of
course, but at this stage they seem to be pretty implementable and to work.For practical purposes, you should feel free to deviate here as I have
done (I should fix it, but it won't make any difference one way or the
other anyway). All that it means is that if you use C_ORDINAL, in the
kernel there needs to be a way to use it to check a DV_ORDINAL instance
(rather than just an ORDINAL).
The reason I try to avoid to create any DV_CODED_TEXT (part of
DV_ORDINAL) in the parser is that it requires access to an Terminology
Service to retrieve the text using CODE_PHRASE (terminologyId and
codeString). That's the exactly the same reason that I argued for
property attribute of C_DV_QUANTITY as type CODE_PHRASE instead of
DV_CODED_TEXT. If C_ORDINAL (essentially an integer with a CODE_PHRASE)
is used instead of DV_ORDINAL, the parser can stay away from the
dependency on TerminologyService, which has been so far avoided.
The kernel always should have access to TerminologyService to be able to
create RM objects. So it's no problem to let the kernel do the the text
retrieval.
Rong