Archetype Editor bug on save after translation
pablo pazos wrote: Several students have experienced problems using the Archetype Editor. When they add a new language to translate an archetype, then save the changes, the changes are not saved. Anyone else is experiencing this problem? Which version of Archetype Editor are they using Pablo? There's a known problem that was introduced in the version 2.2.601 beta release. The problem still exists in the latest 2.2.779 beta release. Editing the comments field could cause an InvalidCastException if the user answered yes to the question whether to replace translations. The problem has been fixed, so if this is the problem that you're running into we could do another beta release with the fix. Are you seeing this, or a different problem? Peter
technical problem CKM
Hi, I think there is some problem in: http://www.openehr.org/knowledge/ Schemes could not be retrieved. Please check your selection and that you have appropriate rights. Release sets could not be loaded. Termsets could not be loaded The teams could not be retrieved. The templates could not be loaded. Archetypes could not be retrieved. etc Looks like a part of the application went offline Thanks Bert Verhees
DV_ORDINAL C_DV_ORDINAL
Hi,
I have some questions, I find hard to explain to my customers.
See below.
But first, I explain how I handle this problem, but I don't know if that
is the best way.
I always tell my customers to create archetypes in the LinkEHR editor,
and if they want a C_DV_QUANTITY, create it by hand in a text-editor
(because the LinkEHR editor does not offer dadl-code inside the
definition, like the Ocean-editor tends to do in case of a DV_QUANTITY
or DV_ORDINAL)
It is a strange thing, because both, Diego Bosca, who is an important
person inside the LinkEHR development, is often on this list.
Also are the Ocean-developers of their Archetype-editor.
There seems however no public discussion between the both approaches
which seem incompatible.
This is not very satisfying.
Below I have the problems I find, worked out.
Can someone please explain what is going on, and how I should explain
this to people which have to work with archetypes.
I was thinking of writing my own archetype-editor, which is not very
hard, with all the published code available (thanks Rong)
But I don't have time, coming months to do so.
But if I would write one, this kind of problems would have been solved,
that is for sure.
I wonder, who's problem is it anyway?
It is mine as developer on OpenEHR-kernel and working with customers.
Thanks a lot
Regards
Bert Verhees
The problem worked out
The LinkEHR editor creates a DV_ORDINAL in ADL if an ORDINAL is wanted.
It looks like this:
DV_ORDINAL[at0015] occurrences matches {0..1} matches { -- DV_ORDINAL
symbol existence
matches {1..1} matches {*}
value existence matches
{1..1} matches {1,2,3; 1}
}
The OCEAN-editor creates a C_DV_ORDINAL which is empty in the definition
but handles the constraint in the term-defitions
ADL-part:
C_DV_ORDINAL
And in the term-definitions, it looks like this (it is under the NodeID
from the parent ELEMENT)
[at0004] =
description = *
a1 = een
text = New element
a2 = twee
-
Both methods are in compatible to each other. Both archetype-editors do
not open each others archetypes.
This is very inconvenient.
Another difference:
The LinkEHR editor offers a NodeID on the DataValue inside the ELEMENT,
giving the opportunity to give the data-value another description (in
the term-definitions) then the ELEMENT has.
The OCEAN does not offer this, but also does not accept archetypes made
by the LinkEHR editor
Even the most simple archetype created by the LinkEHR editor cannot be
opened by the OCEAN editor.
Like this snippet:
definition
EVALUATION[at] occurrences matches {1..1} matches { -- sda
data existence matches {1..1} matches {
ITEM_TREE[at0001] occurrences matches {0..1} matches { --
ITEM_TREE
items existence matches {0..1} cardinality matches
{0..*; unordered; unique} matches {
ELEMENT[at0002] occurrences matches {0..*} matches
{ -- ELEMENT
value existence matches {0..1} matches {
DV_TEXT[at0003] occurrences matches {0..1}
matches {*} -- DV_TEXT
}
}
}
}
}
}
ontology
terminologies_available = ...
term_definitions =
[en-us] =
items =
[at] =
text = sda
description = sda
[at0001] =
text = ITEM_TREE
description = This is a ITEM_TREE object
[at0002] =
text = ELEMENT
description = This is a ELEMENT object
[at0003] =
text = DV_TEXT
description = This is a DV_TEXT object
technical problem CKM
Hi Bert, The server has gone down for some reason. Should be working again now. Sebastian On 23.06.2012 12:15, Bert Verhees wrote: Hi, I think there is some problem in: http://www.openehr.org/knowledge/ Schemes could not be retrieved. Please check your selection and that you have appropriate rights. Release sets could not be loaded. Termsets could not be loaded The teams could not be retrieved. The templates could not be loaded. Archetypes could not be retrieved. etc Looks like a part of the application went offline Thanks Bert Verhees ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Senior Developer Ocean Informatics Skype: gardeseb -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120623/c8930f9b/attachment.html
DV_ORDINAL C_DV_ORDINAL
Hi,
The code-examples were not completely correct. But the issue remains
The LinkEHR editor does not recognize a DV_ORDINAL made by OCEAN,
and also available as, f.e.
openEHR-EHR-OBSERVATION.apgar.v1.adl which I downloaded from CKM.
If I make I DV_ORDINAL in LinkEHR, it looks like this
ELEMENT[at0005] occurrences matches {0..*} matches { -- ELEMENT
value existence matches {0..1}
matches {
DV_ORDINAL[at0006]
occurrences matches {0..1} matches { -- DV_ORDINAL
value existence matches
{1..1} matches {1,2,3; 2}
}
}
}
Which is something else as
ELEMENT[at0009] occurrences matches {0..1} matches {--
Ademhalingsinspanning
value matches {
0|[local::at0010], --
Afwezig
1|[local::at0011], --
Matig of onregelmatig
2|[local::at0012] --
Normaal
}
}
from CKM, which is also created in the Ocean editor, which in another
case created a C_DV_ORDINAL, while I was placing an ORDINAL, but
constructed it in another way.
-
But the DV_QUANTITY and C_DV_QUANTITY between two editors is much more
different, and incompatible in editors, they cannot interchange both
constructs.
Why is that, what is the problem, which one is not following the specs?
And there is also the issue on the NodeID on DataValues, which you can
see also on the DV_ORDINAL in the LinkEHR example
I am having guests now, so I have to stop describing this problem for now
I will come back tomorrow on this subject. But maybe this is enough clue
for the involved people to respond to.
thanks
Bert
Op 23-6-2012 13:01, Bert Verhees schreef:
Hi,
I have some questions, I find hard to explain to my customers.
See below.
But first, I explain how I handle this problem, but I don't know if
that is the best way.
I always tell my customers to create archetypes in the LinkEHR editor,
and if they want a C_DV_QUANTITY, create it by hand in a text-editor
(because the LinkEHR editor does not offer dadl-code inside the
definition, like the Ocean-editor tends to do in case of a DV_QUANTITY
or DV_ORDINAL)
It is a strange thing, because both, Diego Bosca, who is an important
person inside the LinkEHR development, is often on this list.
Also are the Ocean-developers of their Archetype-editor.
There seems however no public discussion between the both approaches
which seem incompatible.
This is not very satisfying.
Below I have the problems I find, worked out.
Can someone please explain what is going on, and how I should explain
this to people which have to work with archetypes.
I was thinking of writing my own archetype-editor, which is not very
hard, with all the published code available (thanks Rong)
But I don't have time, coming months to do so.
But if I would write one, this kind of problems would have been
solved, that is for sure.
I wonder, who's problem is it anyway?
It is mine as developer on OpenEHR-kernel and working with customers.
Thanks a lot
Regards
Bert Verhees
The problem worked out
The LinkEHR editor creates a DV_ORDINAL in ADL if an ORDINAL is
wanted. It looks like this:
DV_ORDINAL[at0015] occurrences matches {0..1} matches { -- DV_ORDINAL
symbol existence
matches {1..1} matches {*}
value existence
matches {1..1} matches {1,2,3; 1}
}
The OCEAN-editor creates a C_DV_ORDINAL which is empty in the
definition but handles the constraint in the term-defitions
ADL-part:
C_DV_ORDINAL
And in the term-definitions, it looks like this (it is under the
NodeID from the parent ELEMENT)
[at0004] =
description = *
a1 = een
text = New element
a2 = twee
-
Both methods are in compatible to each other. Both archetype-editors
do not open each others archetypes.
This is very inconvenient.
Another difference:
The LinkEHR editor offers a NodeID on the DataValue inside the
ELEMENT, giving the opportunity to give the data-value another
description (in the term-definitions) then the ELEMENT has.
The OCEAN does not offer this, but also does not accept archetypes
made by the LinkEHR editor
Even the most simple archetype created by the LinkEHR editor cannot be
opened by the OCEAN editor.
Like this snippet:
definition
EVALUATION[at]
DV_ORDINAL C_DV_ORDINAL
Op 23-6-2012 15:28, Peter Gummer schreef: This seems to be the day for Archetype Editor questions ? first Pablo, and now you:-) It was keeping me busy for some time, but Pablo inspired me to write an email, and also I was working with it now Bert
Archetype Editor bug on save after translation
Hi Peter, I'm using 2.2.779 (and all my students used the same). I don't receive an exception on the GUI (e.g. a dialog/alert windown). Steps:open an ADL file (e.g. openEHR-EHR-EVALUATION.problem_diagnosis.v1.adl)add a new language (e.g. es-UY)change the current language to es-UYchange the first term in the terminology tabclick on save (the diskette button)you will see the * in the title bar (the * appears when a change is made but should disappear when I do the save, this doesn't happen)close the AE (it doesn't alert me of any unsaved changes)open the changed ADL in a text editoryou'll see the new language added, but in the ontology part, the chaged text (translate to es-UY) doesn't appear. Hope that helps. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Subject: Re: Archetype Editor bug on save after translation From: peter.gummer at oceaninformatics.com Date: Sat, 23 Jun 2012 19:37:30 +1000 To: openehr-technical at lists.openehr.org pablo pazos wrote: Several students have experienced problems using the Archetype Editor. When they add a new language to translate an archetype, then save the changes, the changes are not saved. Anyone else is experiencing this problem? Which version of Archetype Editor are they using Pablo? There's a known problem that was introduced in the version 2.2.601 beta release. The problem still exists in the latest 2.2.779 beta release. Editing the comments field could cause an InvalidCastException if the user answered yes to the question whether to replace translations. The problem has been fixed, so if this is the problem that you're running into we could do another beta release with the fix. Are you seeing this, or a different problem? Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120623/27496b4a/attachment.html
Archetype Editor bug on save after translation
Hi Pablo There is a feature in the vb.net grid control used by the terminology pane that means that a changed text in one of the data grid rows fails to register as being changed until the row loses focus Unfortunately the save button does count as a focus control. The work around is to ensure that you change the terminology tab back to the details tab before saving the translated archetype. Also adding another terminology row or clicking on another row should trigger the changed data flag and force the save dialog. I did have a go at fixing this but it turns out to be a nontrivial problem. Ian Dr Ian McNicoll Clinical modelling consultant Ocean Informatics Mobile +44 (0) 775 209 7859 Skype imcnicoll On 23 Jun 2012, at 16:30, pablo pazos pazospablo at hotmail.com wrote: Hi Peter, I'm using 2.2.779 (and all my students used the same). I don't receive an exception on the GUI (e.g. a dialog/alert windown). Steps: 1. open an ADL file (e.g. openEHR-EHR-EVALUATION.problem_diagnosis.v1.adl) 2. add a new language (e.g. es-UY) 3. change the current language to es-UY 4. change the first term in the terminology tab 5. click on save (the diskette button) 6. you will see the * in the title bar (the * appears when a change is made but should disappear when I do the save, this doesn't happen) 7. close the AE (it doesn't alert me of any unsaved changes) 8. open the changed ADL in a text editor 9. you'll see the new language added, but in the ontology part, the chaged text (translate to es-UY) doesn't appear. Hope that helps. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos http://twitter.com/ppazos Subject: Re: Archetype Editor bug on save after translation From: peter.gummer at oceaninformatics.com Date: Sat, 23 Jun 2012 19:37:30 +1000 To: openehr-technical at lists.openehr.org pablo pazos wrote: Several students have experienced problems using the Archetype Editor. When they add a new language to translate an archetype, then save the changes, the changes are not saved. Anyone else is experiencing this problem? Which version of Archetype Editor are they using Pablo? There's a known problem that was introduced in the version 2.2.601 beta release. The problem still exists in the latest 2.2.779 beta release. Editing the comments field could cause an InvalidCastException if the user answered yes to the question whether to replace translations. The problem has been fixed, so if this is the problem that you're running into we could do another beta release with the fix. Are you seeing this, or a different problem? Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120623/6b1286f1/attachment.html
