Dear all,
I am sorry if I this posting is a repetition because I was not able to
follow discussions properly nowadays.
I find it very difficult and not user friendly at all (of course during
manual writing of archetypes, not by using tools) during both authoring
new archetypes or reading other archetypes when an openEHR Terminology
list is used. For example take this one: property = <[openehr::122]>
which means "length"...But I need to open Terminology file, find it and
then say "Aha, I found it". In past, we were able to write down these
terms without referencing to an internal term set and I would still
prefer this way if possible.
For the sake of human-readability of openEHR archetypes I think this is
an important issue.
Maybe both the code and the rubric can be used together or the rubric
can be written as a comment next to the code. But this time we need to
make sure everybody follows the same rule...
Any suggestions?
Best regards,
Koray Atalag, MD
Maybe one should put together a recommendation on how/where to
generate comments in ADL files so that we could do it in similar ways
in different tools? I guess the way it is done now in some tools could
be used as start for that document.
XML-versions of archetypes could also be commented, the recommendation
should cover that too.
Finally would it be a good thing to have an option to switch comment
generation on and off in archetype generating tools, or would it be
better to have it always on? For archetype one point of view could be
that it is best to always generate comments. (Since frequently used
archetypes probably will parsed and then cached in memory, comments
wouldn't impose any big performance degradation).
For RM structures (ehr extracts etc) I guess comment generation also
could be helpful but only should be switched on during development,
testing etc, not in production systems.
Best regards,
Erik Sundvall
http://www.imt.liu.se/~erisu/
Erik Sundvall wrote:
I find it very difficult and not user friendly at all (of course during
manual writing of archetypes, not by using tools) during both authoring
new archetypes or reading other archetypes when an openEHR Terminology
list is used. For example take this one: property = <[openehr::122]>
which means "length"...But I need to open Terminology file, find it and
then say "Aha, I found it". In past, we were able to write down these
terms without referencing to an internal term set and I would still
prefer this way if possible.
Maybe both the code and the rubric can be used together or the rubric
can be written as a comment next to the code. But this time we need to
make sure everybody follows the same rule...
Maybe one should put together a recommendation on how/where to
generate comments in ADL files so that we could do it in similar ways
in different tools? I guess the way it is done now in some tools could
be used as start for that document.
XML-versions of archetypes could also be commented, the recommendation
should cover that too.
Finally would it be a good thing to have an option to switch comment
generation on and off in archetype generating tools, or would it be
better to have it always on? For archetype one point of view could be
that it is best to always generate comments. (Since frequently used
archetypes probably will parsed and then cached in memory, comments
wouldn't impose any big performance degradation).
For RM structures (ehr extracts etc) I guess comment generation also
could be helpful but only should be switched on during development,
testing etc, not in production systems.
Best regards,
Erik Sundvall
http://www.imt.liu.se/~erisu/
_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Hi Eric,
I agree with you on the matter of comments...The more we have comments
better understandability for humans.
However apart from putting the meanings next to the term codes as
comments, I am now more inclined towards putting both the text and the
rubric together as it happens in Elements as name and value pairs.
Best regards,
Koray Atalag, MD