# Archetype-editors **Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158) **Created:** 2006-09-18 13:56 UTC **Views:** 100 **Replies:** 27 **URL:** https://discourse.openehr.org/t/archetype-editors/14570 --- ## Post #1 by @system Hi, I have three archetype\-editors, the overal quality is low\. This is a bad thing\. I use the written in Eiffel Archetype Workbench The in VB\.DOTNET editor from Ocean and the Java\-editor\. I wonder if images come through in this list, this is my archetype, still building\. The ocean error produces an error message, when loading an archetype created in the ADL\-workbench\. I print the error\-message below\. The Java\-editor changes the archetype \(very dangerous\), without warning The constraint is this: 40 \} 41 ELEMENT\[at0006\] occurrences matches \{1\.\.1\} matches \{ 42 value matches \{|>0|\} 43 \} 44 \} 45 \} The java\-editor makes this          \}             ELEMENT\[at0006\] occurrences matches \{1\.\.1\} matches \{\*\}         \} Te Ocean editor does this, by the way, it also changes the archetype, also without warning: --- ## Post #2 by @Mattias_Forss1 2006/9/18, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)>: > Hi, I have three archetype-editors, the overal quality is low. This is a > bad thing. > > I use the written in Eiffel Archetype Workbench > The in VB.DOTNET editor from Ocean > and the Java-editor. I wonder if images come through in this list, this > is my archetype, still building. > > The ocean error produces an error message, when loading an archetype > created in the ADL-workbench. I print the error-message below. > The Java-editor changes the archetype (very dangerous), without warning > > The constraint is this: > 40 } > 41 ELEMENT[at0006] occurrences matches {1..1} matches { > 42 value matches {|>0|} > 43 } > 44 } > 45 } > > The java-editor makes this > } > ELEMENT[at0006] occurrences matches {1..1} matches {*} > } It's because it's not a vaild openEHR data type, i.e. not a vaild openEHR archetype. If u want to add support for other reference model you can do that when the source is released. /Mattias --- ## Post #3 by @system > > It's because it's not a vaild openEHR data type, i\.e\. not a vaild openEHR archetype\. If u want to add support for other reference model you can do that when the source is released\. I am sorry, but I don't understand\. I created these archetypes with the java\-archetype\-editor, and also once with the Ocean archetype editor, and even the ADL\-workbench parses it, and shows a nice trtee, with all tree elements correctly described Can you please explain what the problem is? Thanks Bert --- ## Post #4 by @system > > It's because it's not a vaild openEHR data type, i\.e\. not a vaild openEHR archetype\. If u want to add support for other reference model you can do that when the source is released\. I am sorry, but I don't understand\. I created these archetypes with the java\-archetype\-editor, and also once with the Ocean archetype editor, and even the ADL\-workbench parses it, and shows a nice trtee, with all tree elements correctly described Can you please explain what the problem is? Thanks Bert --- ## Post #5 by @system Bert Verhees schreef: > >> It's because it's not a vaild openEHR data type, i\.e\. not a vaild openEHR archetype\. If u want to add support for other reference model you can do that when the source is released\. > > I am sorry, but I don't understand\. I created these archetypes with the > java\-archetype\-editor, and also once with the Ocean archetype editor, > and even the ADL\-workbench parses it, and shows a nice trtee, with all > tree elements correctly described I tried it again, it was not the java\-editor which created it, it is because I diod so many things, that I forgot\. It was the ADL documentation, which, in my opinion, explained that this was legal\. See the latest version, chapter 4\.4\.2\.2 And the ADL workbench eats it and shows in a tree met the correct image\. It is both Archetype\-editors which refuse to load this\. Thanks Bert Verhees --- ## Post #6 by @system Bert Verhees schreef: > Bert Verhees schreef: >> >>> It's because it's not a vaild openEHR data type, i\.e\. not a vaild openEHR archetype\. If u want to add support for other reference model you can do that when the source is released\. >> >> I am sorry, but I don't understand\. I created these archetypes with the >> java\-archetype\-editor, and also once with the Ocean archetype editor, >> and even the ADL\-workbench parses it, and shows a nice trtee, with all >> tree elements correctly described > > I tried it again, it was not the java\-editor which created it, it is because I diod so many things, that I forgot\. > It was the ADL documentation, which, in my opinion, explained that this was legal\. > > See the latest version, chapter 4\.4\.2\.2 > > And the ADL workbench eats it and shows in a tree met the correct image\. > > It is both Archetype\-editors which refuse to load this\. I just downloaded the archetype\-editor from ocean 0\.99\.7\.f A small character far behind in the version indicator can make al lot of difference, it seems to work very good\. Thanks Bert Verhees --- ## Post #7 by @system Bert Verhees schreef: > Bert Verhees schreef: >> >>> It's because it's not a vaild openEHR data type, i\.e\. not a vaild openEHR archetype\. If u want to add support for other reference model you can do that when the source is released\. >> >> I am sorry, but I don't understand\. I created these archetypes with the >> java\-archetype\-editor, and also once with the Ocean archetype editor, >> and even the ADL\-workbench parses it, and shows a nice trtee, with all >> tree elements correctly described > > I tried it again, it was not the java\-editor which created it, it is because I diod so many things, that I forgot\. > It was the ADL documentation, which, in my opinion, explained that this was legal\. > > See the latest version, chapter 4\.4\.2\.2 But still there is a problem with this construct ELEMENT\[at0016\] matches \{ \-\- Aantal herhalingen                 value matches \{|>= 0|\}             \} It translates it like this ELEMENT\[at0016\] matches \{\*\} Even the comment has fallen off\. --- ## Post #8 by @thomas.beale Bert Verhees wrote: > Bert Verhees schreef: >> I am somewhat confused with all these messages Bert, but I'll try to work out what you are saying here\.\.\.\. > But still there is a problem with this construct > > ELEMENT\[at0016\] matches \{ \-\- Aantal herhalingen >                value matches \{|>= 0|\} >            \} this contravenes the openEHR reference model, as Mattias said\.\.\.\.the type of value in ELEMENT is not Integer, as the above syntax implies, but\-DATA\_VALUE, so the concrete type has to be any of the DV\_XXX types\. > > It translates it like this > > ELEMENT\[at0016\] matches \{\*\} which tool is doing this? > > Even the comment has fallen off\. > \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- > It accepts something like this > > ELEMENT\[at0106\] occurrences matches \{0\.\.1\} matches \{ \-\- New element >                value matches \{ >                    COUNT matches \{ >                        magnitude matches \{|>= 0|\} >                    \} >                \} >            \} yes, exactly, this is what is needed to satisfy the openEHR reference model\. > Is that the way how I should write above statement? > It does not seem in line with 4\.4\.2\.2 from the ADL document this section describes constraints on Integer, but you are constraining a DV\_XXX type, e\.g\. DV\_COUNT etc\. Note that we allow the DV\_ to be missing to make the type names a but less ugly and openEHR\-oriented \(but the semantics are openEHR\)\. hope this helps\. \- thomas --- ## Post #9 by @system Thomas Beale schreef: > Bert Verhees wrote: >> Bert Verhees schreef: >>> > > I am somewhat confused with all these messages Bert, but I'll try to work out what you are saying here\.\.\.\. Thanks for trying, excuse me for the mess\. >> But still there is a problem with this construct >> >> ELEMENT\[at0016\] matches \{ \-\- Aantal herhalingen >>                value matches \{|>= 0|\} >>            \} > > this contravenes the openEHR reference model, as Mattias said\.\.\.\.the type of value in ELEMENT is not Integer, as the above syntax implies, but\-DATA\_VALUE, so the concrete type has to be any of the DV\_XXX types\. That is what I did overlook >> >> It translates it like this >> >> ELEMENT\[at0016\] matches \{\*\} > > which tool is doing this? Both, Ocean and Swedish archetype editor did\. >> >> Even the comment has fallen off\. >> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- >> It accepts something like this >> >> ELEMENT\[at0106\] occurrences matches \{0\.\.1\} matches \{ \-\- New element >>                value matches \{ >>                    COUNT matches \{ >>                        magnitude matches \{|>= 0|\} >>                    \} >>                \} >>            \} > > yes, exactly, this is what is needed to satisfy the openEHR reference model\. Thanks > >> Is that the way how I should write above statement? >> It does not seem in line with 4\.4\.2\.2 from the ADL document > > this section describes constraints on Integer, but you are constraining a DV\_XXX type, e\.g\. DV\_COUNT etc\. Note that we allow the DV\_ to be missing to make the type names a but less ugly and openEHR\-oriented \(but the semantics are openEHR\)\. Thanks Thomas, this is really a helpful answer Bert --- ## Post #10 by @system One itsy pitsy tiny thing The Ocean Editor puts \(adl\_version=1\.4\) in line 1 of the ADL, on which the ADL\-Workbench stumbles\. regards Bert --- ## Post #11 by @thomas.beale Bert Verhees wrote: > One itsy pitsy tiny thing > > The Ocean Editor puts \(adl\_version=1\.4\) in line 1 of the ADL, on which the ADL\-Workbench stumbles\. > > regards > Bert > I'm not sure what the problem can be here\.\.\.\.all the openEHR archetypes have this, and the workbench processes them all correctly\. Can you specify how you caused the error more precisely? thanks, \- thomas --- ## Post #12 by @system Thomas Beale schreef: > Bert Verhees wrote: >> One itsy pitsy tiny thing >> >> The Ocean Editor puts \(adl\_version=1\.4\) in line 1 of the ADL, on which the ADL\-Workbench stumbles\. >> >> regards >> Bert >> > > I'm not sure what the problem can be here\.\.\.\.all the openEHR archetypes have this, and the workbench processes them all correctly\. Can you specify how you caused the error more precisely? It says this: ERROR \- line 1: parse error \[last token = V\_IDENTIFIER\] \(Parse failed\) \(ADL\_INTERFACE\.parse\_archetype\) And stops parsing, when I remove that part \(adl\_version=1\.4\) it works fine\. I use ADL\_Workbench, I don't know, I think the Aboutbox it is never updated\. But I always do a checkout with SVN and compile it myself in Eiffel\. If I do a SVN update, nothing comes, so it must be the latest\. --- ## Post #13 by @Mattias_Forss1 2006/9/18, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)>: > Hi, I have three archetype-editors, the overal quality is low. This is a > bad thing. > > This really is a bad situation, I can understand that this scares off > technical oriented people. > > I must work together with a GP, who creates the archetypes, he would > like to use an Archetype-editor, but he has had it with the offered > software. So now he sends me Word-documents with archetypes described, > and I must create them. Bert, It would be nice if you provided _actual feedback_ instead of just complaining that the editors are bad overall, since that's not constructive criticism whatsoever. If I get concrete feedback on experienced problems I could try to improve the Java archetype editor. Actually, I have made several major usability/bug fixes in the current code base of the editor compared to the public version 0.3 and I hope the next version (which will be open sourced) will soothe your GP friend's nerves. I try to keep quality and usability thinking in mind when I develop and I again urge you to provide feedback on the negative parts. The last thing I want to do is scare off people from using the software because it is supposed to be a tool that creates stable, and correct openEHR archetypes compared to the process of writing ADL manually, which is prone to producing all kinds of errors, unless you have a built-in ADL-parser in your brain that is. Regarding support for other reference models (e.g. your constraints on Integer instead of using an openEHR DATA_VALUE, DV_COUNT), that will take some time (for one person to do) and will probably not be supported in the nearest future. > I am using the three tools simultaneous, reopen archetypes, save them, etc. > ------- > > One can say, I should be glad that I get this software to use for free, > but that is not my position, nothing comes for free. > This software is published, not to please me, but for other purposes, > that have nothing to do with me. > > Now my question: > Which archetype editor is right? Is this archetype OK, or is it not? Not according to the openEHR reference model. Regards, Mattias --- ## Post #14 by @Mattias_Forss1 2006/9/18, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)>: > Bert Verhees schreef: > > Bert Verhees schreef: > >> > >>> > >>> > >>> It's because it's not a vaild openEHR data type, i.e. not a vaild > >>> openEHR archetype. If u want to add support for other reference > >>> model you can do that when the source is released. > >> I am sorry, but I don't understand. I created these archetypes with the > >> java-archetype-editor, and also once with the Ocean archetype editor, > >> and even the ADL-workbench parses it, and shows a nice trtee, with all > >> tree elements correctly described > > > > I tried it again, it was not the java-editor which created it, it is > > because I diod so many things, that I forgot. > > It was the ADL documentation, which, in my opinion, explained that > > this was legal. > > > > See the latest version, chapter [**MailScanner has detected a possible fraud attempt from "4.4.2.2" claiming to be** **MailScanner warning: numerical links are often malicious: 4.4.2.2**](http://4.4.2.2) > **But still there is a problem with this construct** > > **ELEMENT[at0016] matches { -- Aantal herhalingen** > **value matches {|>= 0|}** > **}** Bert, You can not expect that the archetype editor will recognize an archetype anymore once you've been editing it manually. In order to create archetypes that conform to the openEHR reference model, they are supposed to be created with the widgets in the user interface... Every time you have an ADL-file which has openEHR in the archetype identifier, that reference model will be considered and things not recognized might disappear. Consequently, you must be very careful to make sure that the files you're editing manually are conforming to the openEHR reference model. Anyways, there should probably be some log about what was not recognized and what was converted, removed etc. For instance, in the newest version of the editor all leaf constrains on Integer under ELEMENTs will be converted to DV_COUNT. Other conversions are also made, but only a few are logged and they are only logged to the console at the moment. But as long as the file isn't saved the user can always chose to quit without saving the file if the editor has converted or removed something that the user (for some reason) wants to keep. Regards, Mattias --- ## Post #15 by @Mattias_Forss1 2006/9/18, Mattias Forss <[mattias.forss@gmail.com](mailto:mattias.forss@gmail.com)>: > 2006/9/18, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)>: > > > Bert Verhees schreef: > > > Bert Verhees schreef: > > >> > > >>> > > >>> > > >>> It's because it's not a vaild openEHR data type, i.e. not a vaild > > >>> openEHR archetype. If u want to add support for other reference > > >>> model you can do that when the source is released. > > >> I am sorry, but I don't understand. I created these archetypes with the > > >> java-archetype-editor, and also once with the Ocean archetype editor, > > >> and even the ADL-workbench parses it, and shows a nice trtee, with all > > >> tree elements correctly described > > > > > > I tried it again, it was not the java-editor which created it, it is > > > because I diod so many things, that I forgot. > > > It was the ADL documentation, which, in my opinion, explained that > > > this was legal. > > > > > > See the latest version, chapter [**MailScanner has detected a possible fraud attempt from "4.4.2.2" claiming to be** **MailScanner warning: numerical links are often malicious: 4.4.2.2**](http://4.4.2.2/) > > **But still there is a problem with this construct** > > > > **ELEMENT[at0016] matches { -- Aantal herhalingen** > > **value matches {|>= 0|}** > > **}** > > > > Bert, > > You can not expect that the archetype editor will recognize an archetype anymore once you've been editing it manually. In order to create archetypes that conform to the openEHR reference model, they are supposed to be created with the widgets in the user interface... Every time you have an ADL-file which has openEHR in the archetype identifier, that reference model will be considered and things not recognized might disappear. Consequently, you must be very careful to make sure that the files you're editing manually are conforming to the openEHR reference model. > > Anyways, there should probably be some log about what was not recognized and what was converted, removed etc. For instance, in the newest version of the editor all leaf constrains on Integer under ELEMENTs will be converted to DV_COUNT. Other conversions are also made, but only a few are logged and they are only logged to the console at the moment. But as long as the file isn't saved the user can always chose to quit without saving the file if the editor has converted or removed something that the user (for some reason) wants to keep. > > Regards, > > Mattias > > > It translates it like this > > > > ELEMENT[at0016] matches {*} > > > > Even the comment has fallen off. > > The missing comment has to do with the ADL Serializer which needs to be updated for this. But it's merely a readability issue, it's not changing the semantics of the ADL. /Mattias --- ## Post #16 by @system Mattias Forss schreef: > > 2006/9/18, Bert Verhees <bert\.verhees@rosa\.nl <mailto:bert.verhees@rosa.nl>>: > >     Hi, I have three archetype\-editors, the overal quality is low\. >     This is a >     bad thing\. > >     This really is a bad situation, I can understand that this scares off >     technical oriented people\. > >     I must work together with a GP, who creates the archetypes, he would >     like to use an Archetype\-editor, but he has had it with the offered >     software\. So now he sends me Word\-documents with archetypes >     described, >     and I must create them\. > > Bert, > It would be nice if you provided \_actual feedback\_ instead of just complaining that the editors are bad overall, since that's not constructive criticism whatsoever\. If I get concrete feedback on Sorry Mattias, I do not want to start a flame, that is not my intention\. It is just very difficult to work with three different ADL tools which all have a slightly different opinion about what ADL is, and than a ADL\-document, which puts me on a wrong track\. I explained it with an example, a ADL\-situation, and in the end there was some misunderstanding from my side, Thomas discovered quick \(happily\), and someone else pointed me privately to the updated Ocean archetypeeidtor, which is really much better\. \(the previous I used showed no text in the context menu's, I had to click on whitespace, and it crashed a lot, I also had one which only showed Arabic characters, really, what went wrong I don't know\)\. Feedback: You can see the ADL\-example as a kind of feedback\. I do not want to flame, I want to work to a solution\. Time\-pressure Working on a moving target \(as we say in Dutch\) is also very difficult\. Because I work on an older kernel version, it is a real commercial project, and I said many times, the time\-pressure is enormous, I have no time, at this moment to update the kernel, I must manually translate the archetypes to that kernel version\. I wrote a archetype\-validator, so I can check them\. I did backport some patches from later kernelversions to repair small issues in "my" kernel\. I will update as soon I have time, which I hope will be in one month or so\. Life will be so much easier then\. And at the end of this day, all my problems are solved\. And I can do what I intended to do in the beginning of the day\. I agree partially, the problems where my own fault, my misunderstanding\. That is how things can go\. And I work alone, so sometimes, one cannot see his owns mistakes\. > experienced problems I could try to improve the Java archetype editor\. Actually, I have made several major usability/bug fixes in the current code base of the editor compared to the public version 0\.3 and I hope the next version \(which will be open sourced\) will soothe your GP friend's nerves\. Yes I hope so to\. It soothes also my nerves, I am an open source freak, because I hate it being depending on someone I hardly know\. There is a small wish list for your Archetype Editor\. And maybe I can do that myself, if you don't do that, for whatever reasons\. But I saw, I analyzed the jar\-file, and I saw, there were a lot of libraries in use, which I don't know, lot of them to do with the GUI\. That takes a lot of study\. I hope, I can step easily into the code, we'll see\. > I try to keep quality and usability thinking in mind when I develop and I again urge you to provide feedback on the negative parts\. The last thing I want to do is scare off people from using the software because it is supposed to be a tool that creates stable, and correct openEHR archetypes compared to the process of writing ADL manually, which is prone to producing all kinds of errors, unless you have a built\-in ADL\-parser in your brain that is\. > Regarding support for other reference models \(e\.g\. your constraints on Integer instead of using an openEHR DATA\_VALUE, DV\_COUNT\), that will take some time \(for one person to do\) and will probably not be supported in the nearest future\. Yes, that was a stupid misunderstanding\. Also, it was the ADL\-document which confirmed me on my wrong leg\. I read it again, I even did a search in the document to "DV\_", it does not exist in the document, but all kind of constraints are explained which are not part of the OpenEhr model\. I don't know what to think of that, for what purpose that document is published\. One can use the information in the DV\_XXX's, but that is not explained\. Anyway, another day older, doesn't matter Thanks and regards Bert Verhees --- ## Post #17 by @system Mattias Forss schreef: > 2006/9/18, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)>: > > > Bert Verhees schreef: > > > Bert Verhees schreef: > > >> > > >>> > > >>> > > >>> It's because it's not a vaild openEHR data type, i.e. not a vaild > > >>> openEHR archetype. If u want to add support for other reference > > >>> model you can do that when the source is released. > > >> I am sorry, but I don't understand. I created these archetypes with the > > >> java-archetype-editor, and also once with the Ocean archetype editor, > > >> and even the ADL-workbench parses it, and shows a nice trtee, with all > > >> tree elements correctly described > > > > > > I tried it again, it was not the java-editor which created it, it is > > > because I diod so many things, that I forgot. > > > It was the ADL documentation, which, in my opinion, explained that > > > this was legal. > > > > > > See the latest version, chapter [**MailScanner has detected a possible fraud attempt from "4.4.2.2" claiming to be** **MailScanner warning: numerical links are often malicious: 4.4.2.2**](http://4.4.2.2) > > **But still there is a problem with this construct** > > > > **ELEMENT[at0016] matches { -- Aantal herhalingen** > > **value matches {|>= 0|}** > > **}** > > **Bert,** > > **You can not expect that the archetype editor will recognize an archetype anymore once you've been editing it manually. In order to create archetypes that conform to the openEHR reference model, they are supposed to be created with the widgets in the user interface... Every time you have an ADL-file which has openEHR in the archetype identifier, that** That is too bad, it is on my wish list, it should be like opening an ADL-file. But I know what the weak point is, you have written your ADL-parser yourself, to overcome the immutable lists Rong did program. That was not necessary. Because the parser from Rong, is very good, and searches the text for pattern, so it can create objects from the ADL, even if it did not write it itself. The ADLparser from Rong also has detailed error messages, could improve but already very good. That is how a archetype editor can work two ways, making it possible to edit in text and to edit in GUI. All these things are for free if you could overcome the immutable lists. I did overcome them, I create archetypes in code, while parsing HL7 XSD files. I stopped that project for other reasons, but the principle of code can be used in your archetype editor. If it is easy to exchange your ADL parser with that of Rong, you can win a lot of functionality without much programming. You even can support more versions of ADL simultaneous. But not many people will ever need that. But you will get automatically patched if there are errors and you can travel with Rong to ADL version 2, and surely there will be a 2.0.1. You can also look at the ADL workbench which has a nice parser, a bit slow, I must admit, but produces a nice GUI after parsing, or does nice error messages if it does not succeed parsing. Lots of opportunities. > **reference model will be considered and things not recognized might disappear. Consequently, you must be very careful to make sure that the files you're editing manually are conforming to the openEHR reference model.** It is possible to do checks, just ask the kernelobjects if they can handle what you deliver. it does not guarantee openehr model, but it guarantees valid ADL. Also this is an advantage if you can use the kernel inside your editor. You, with your knowledge of what a valid OpenEHR model is, can than add the logic, that if ADL is valid, to check the model. You have to write that part anyway, and that part is not fully integrated in the kernel, but some checks are. > **Anyways, there should probably be some log about what was not recognized and what was converted, removed etc. For instance, in the newest version of the editor all leaf constrains on Integer under ELEMENTs will be converted to DV_COUNT. Other conversions are also made, but only a few are logged and they are only logged to the console at the moment. But as long as the file isn't saved the user can always chose to quit without saving the file if the editor has converted or removed something that the user (for some reason) wants to keep.** That is true. But I didn't know the editor had changed my ADL, which was valid as ADL, and I disovered accidently that it happened. Because, when I had saved my file, f.e. after issueing a small change. It can easily happen. Nice color Red, is it because of red loosing the elections in Sweden? ;-) just joking regards Bert Verhees --- ## Post #18 by @rong.chen > > It translates it like this > > > > > > ELEMENT\[at0016\] matches \{\*\} > > > > > > Even the comment has fallen off\. > > > > > The missing comment has to do with the ADL Serializer which needs to be > updated for this\. But it's merely a readability issue, it's not changing the > semantics of the ADL\. Actually, comments within the ADL are not handled by the parser at the moment \- they are just skipped as white space during parsing\. Also there is no place to store them in the AOM\. That's why the serializer doesn't know anything about comments\. Hope this helps\. Rong --- ## Post #19 by @Mattias_Forss1 2006/9/19, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)>: > Mattias Forss schreef: > > > > > > 2006/9/18, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl) > > >: > > > > Hi, I have three archetype-editors, the overal quality is low. > > This is a > > bad thing. > > > > This really is a bad situation, I can understand that this scares off > > technical oriented people. > > > > I must work together with a GP, who creates the archetypes, he would > > like to use an Archetype-editor, but he has had it with the offered > > software. So now he sends me Word-documents with archetypes > > described, > > and I must create them. > > > > > > Bert, > > > > It would be nice if you provided _actual feedback_ instead of just > > complaining that the editors are bad overall, since that's not > > constructive criticism whatsoever. If I get concrete feedback on > Sorry Mattias, I do not want to start a flame, that is not my intention. > It is just very difficult to work with three different ADL tools which > all have a slightly different opinion about what ADL is, and than a > ADL-document, which puts me on a wrong track. I don't want to start a flame either. Sorry if you got that impression from my answer. Yes, the tools diverge a little bit at the moment, but that will hopefully change soon. > There is a small wish list for your Archetype Editor. And maybe I can do > that myself, if you don't do that, for whatever reasons. It would be nice if I could get hold of that wish list somehow, but if you want to do the changes yourself, that's fine. > But I saw, I analyzed the jar-file, and I saw, there were a lot of > libraries in use, which I don't know, lot of them to do with the GUI. > That takes a lot of study. I hope, I can step easily into the code, > we'll see. Hopefully it's not that difficult. You will probably not need to use any of the libraries (only kernel, parser and serializer), they are mostly used for the external terminology sources/services. > > > > Regarding support for other reference models (e.g. your constraints on > > Integer instead of using an openEHR DATA_VALUE, DV_COUNT), that will > > take some time (for one person to do) and will probably not be > > supported in the nearest future. > Yes, that was a stupid misunderstanding. Also, it was the ADL-document > which confirmed me on my wrong leg. I read it again, I even did a search > in the document to "DV_", it does not exist in the document, but all > kind of constraints are explained which are not part of the OpenEhr > model. I don't know what to think of that, for what purpose that > document is published. > One can use the information in the DV_XXX's, but that is not explained. The ADL document is only explaining the allowed syntax in ADL. If you want to know the valid data structures, data types, etc. you will have to study the documents in the RM section ( i.e. the Reference Model). Currently, there is no document which thoroughly explains how the ADL constraints of the RM are supposed to be written in the archetypes (some things of the RM aren't supposed to be constrained in archetypes) but other archetypes can be studied to get the idea. Regards, Mattias --- ## Post #20 by @Mattias_Forss1 2006/9/19, Rong Chen <[rong@acode.se](mailto:rong@acode.se)>: > > > It translates it like this > > > > > > > > ELEMENT[at0016] matches {*} > > > > > > > > Even the comment has fallen off. > > > > > > > > The missing comment has to do with the ADL Serializer which needs to be > > updated for this. But it's merely a readability issue, it's not changing the > > semantics of the ADL. > > Actually, comments within the ADL are not handled by the parser at the moment - they are just skipped as white space during parsing. Also there is no place to store them in the AOM. That's why the serializer doesn't know anything about comments. Yes, but I was referring to when the comments are only the description part of the node IDs, which mostly is the case. Mattias --- ## Post #21 by @Mattias_Forss1 2006/9/19, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)>: > Mattias Forss schreef: > > > 2006/9/18, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl) >: > > > > > Bert Verhees schreef: > > > > Bert Verhees schreef: > > > >> > > > >>> > > > >>> > > > >>> It's because it's not a vaild openEHR data type, i.e. not a vaild > > > >>> openEHR archetype. If u want to add support for other reference > > > >>> model you can do that when the source is released. > > > >> I am sorry, but I don't understand. I created these archetypes with the > > > >> java-archetype-editor, and also once with the Ocean archetype editor, > > > >> and even the ADL-workbench parses it, and shows a nice trtee, with all > > > >> tree elements correctly described > > > > > > > > I tried it again, it was not the java-editor which created it, it is > > > > because I diod so many things, that I forgot. > > > > It was the ADL documentation, which, in my opinion, explained that > > > > this was legal. > > > > > > > > See the latest version, chapter [**MailScanner has detected a possible fraud attempt from "4.4.2.2" claiming to be** **MailScanner warning: numerical links are often malicious: 4.4.2.2**](http://4.4.2.2) > > > **But still there is a problem with this construct** > > > > > > **ELEMENT[at0016] matches { -- Aantal herhalingen** > > > **value matches {|>= 0|}** > > > **}** > > > > **Bert,** > > > > **You can not expect that the archetype editor will recognize an archetype anymore once you've been editing it manually. In order to create archetypes that conform to the openEHR reference model, they are supposed to be created with the widgets in the user interface... Every time you have an ADL-file which has openEHR in the archetype identifier, that** > > That is too bad, it is on my wish list, it should be like opening an ADL-file. > But I know what the weak point is, you have written your ADL-parser yourself, to overcome the immutable lists Rong did program. That was not necessary. Because the parser from Rong, is very good, and searches the text for pattern, so it can create objects from the ADL, even if it did not write it itself. The ADLparser from Rong also has detailed error messages, could improve but already very good. > That is how a archetype editor can work two ways, making it possible to edit in text and to edit in GUI. No, I haven't written my own ADL-parser, I use the one provided by Rong Chen. To overcome the immutable lists there is an internal model in the editor, but that's a design decision (made on very limited time) but it will not affect the functionality of the program. If I want to, I can improve the internal model to be more general and allow more things but that concerns your archetypes, which follow another reference model. These archetypes must also replace the openEHR in the archetype identifier so that the editor will know that it must treat the archetype in a more general way. That functioanlity however, is currently not provided in any of the archetype editors. Support for other (unknown) reference models could be implemented later. We could also decide to use the AOM internally, but it would still be good to have simple facade classes to the AOM so that the logic for doing small changes in the GUI, e.g. setting run time name constraints, setting cardinality is easy to follow. The benefits of using the AOM will of course be that things not recognized in the GUI will stay the same and if the user wants to, the file could be checked for complete openEHR validity and then remove/convert illegal things. At this moment however, I see that there is very much work in replacing the internal model with the AOM. I don't think you fully understand how much effort it takes to map GUI widgets to the AOM since you haven't implemented an archetype editor yourself. However, it's a logical thing to do with the editor in the future, but God didn't make the world in one day and I certainly will not manage to make these changes in one day ;-) > All these things are for free if you could overcome the immutable lists. I did overcome them, I create archetypes in code, while parsing HL7 XSD files. I stopped that project for other reasons, but the principle of code can be used in your archetype editor. If it is easy to exchange your ADL parser with that of Rong, you can win a lot of functionality without much programming. You even can support more versions of ADL simultaneous. But not many people will ever need that. But you will get automatically patched if there are errors and you can travel with Rong to ADL version 2, and surely there will be a 2.0.1. > > You can also look at the ADL workbench which has a nice parser, a bit slow, I must admit, but produces a nice GUI after parsing, or does nice error messages if it does not succeed parsing. > > Lots of opportunities. > > > **reference model will be considered and things not recognized might disappear. Consequently, you must be very careful to make sure that the files you're editing manually are conforming to the openEHR reference model.** > > It is possible to do checks, just ask the kernelobjects if they can handle what you deliver. it does not guarantee openehr model, but it guarantees valid ADL. Also this is an advantage if you can use the kernel inside your editor. > You, with your knowledge of what a valid OpenEHR model is, can than add the logic, that if ADL is valid, to check the model. You have to write that part anyway, and that part is not fully integrated in the kernel, but some checks are. Yes, I know that but it requires some work, see above. I'm not sure if asking the kernel objects is the right thing if older archetypes are supposed to be supported in order to convert them to newer archetypes. We might need some other reference information than kernel objects when we convert archetypes based on older versions of the kernel, since older archetypes in many cases do not follow the reference model ;-) > > **Anyways, there should probably be some log about what was not recognized and what was converted, removed etc. For instance, in the newest version of the editor all leaf constrains on Integer under ELEMENTs will be converted to DV_COUNT. Other conversions are also made, but only a few are logged and they are only logged to the console at the moment. But as long as the file isn't saved the user can always chose to quit without saving the file if the editor has converted or removed something that the user (for some reason) wants to keep.** > > That is true. But I didn't know the editor had changed my ADL, which was valid as ADL, and I disovered accidently that it happened. Because, when I had saved my file, f.e. after issueing a small change. It can easily happen. It should be possible to view a log if something changed... > Nice color Red, is it because of red loosing the elections in Sweden? > ;-) just joking Nice one. Regards, Mattias --- ## Post #22 by @system Another good thing for the editor would be the possibility to edit the KEY \(identifier\) in the definition, and do good checks that if they are changed manually, they are also changed in ontology Why would one want to edit keys? Sometimes it is very handy to have this possibility, f\.e\. because one wants to make items from a list too have a different key\-system to make them recognizable\. Programmers often do that kind of things, giving local variables other names as globals, etc\. In my case, I had give list\-items a number above 100 \(at0100\) and other items below, just for readability, and what happens, the Ocean editor starts giving numbers above 100\. I do not like an archetype\-editor to have an opinion about my numbering system\. The best thing that could happen to ADL\-developers is the ADL workbench, it has a nice reward if loading succeeds, by showing a nice node\-map, it has a good error\-message system, and it is permissive as it comes to the openehr model, it accepts all valid ADL, which I see as a feature\. thanks Bert --- ## Post #23 by @Mattias_Forss1 2006/9/19, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)>: > Another good thing for the editor would be the possibility to edit the > KEY (identifier) in the definition, and do good checks that if they are > changed manually, they are also changed in ontology > > Why would one want to edit keys? > > Sometimes it is very handy to have this possibility, f.e. because one > wants to make items from a list too have a different key-system to make > them recognizable. It is probably quite easy to add this functionality, but there should be some checks so it's not possible to change to a nodeID that is already defined, because they are supposed to be unique. /Mattias --- ## Post #24 by @thomas.beale Everyone, there is a lot of work, fun, learning, and the occasional bit of angst here! Let's try and channel some of this energy. My suggestion is that we build some organised wishlists, which can become formal change requests, but let's not quite go there yet. My suggestion is that we as a group think about changes and enhancements for these things: - the Java parser - the Eiffel reference parser (what is inside the Workbench and the Ocean editor) - the Linköping archetype editor - the Ocean archetype editor - the ADL workbench can we document what we want on this basis? I think it will make things clearer... I have already proposed to get an openEHR wiki up and running but it might take a while longer than I thought - there is a certain amount of sysadmin to do to make it happen, and we need to plan for disc space etc etc. So in the interim, let's use posts on this list to keep a track of such things (e.g. under a "wishlist" thread) and we'll move it to the wiki later. - thomas --- ## Post #25 by @Mattias_Forss1 2006/9/19, Thomas Beale <[Thomas.Beale@oceaninformatics.biz](mailto:Thomas.Beale@oceaninformatics.biz)>: > Everyone, > > there is a lot of work, fun, learning, and the occasional bit of angst here! Let's try and channel some of this energy. My suggestion is that we build some organised wishlists, which can become formal change requests, but let's not quite go there yet. My suggestion is that we as a group think about changes and enhancements for these things: > > - the Java parser > - the Eiffel reference parser (what is inside the Workbench and the Ocean editor) > - the Linköping archetype editor > - the Ocean archetype editor > - the ADL workbench > can we document what we want on this basis? I think it will make things clearer... Hi Thomas, I and Erik discussed this briefly. We think it's a good idea. /Mattias --- ## Post #26 by @rong.chen > > > > > > Everyone, > > > > there is a lot of work, fun, learning, and the occasional bit of angst > > here\! Let's try and channel some of this energy\. My suggestion is that we > > build some organised wishlists, which can become formal change requests, but > > let's not quite go there yet\. My suggestion is that we as a group think > > about changes and enhancements for these things: > > > > \- the Java parser > > \- the Eiffel reference parser \(what is inside the Workbench and the > > Ocean editor\) > > \- the Linköping archetype editor > > \- the Ocean archetype editor > > \- the ADL workbench > > > > can we document what we want on this basis? I think it will make things > > clearer\.\.\. > > > > Hi Thomas, > > I and Erik discussed this briefly\. We think it's a good idea\. I too think it's a great idea\. First thing first \- the interoperability between the openehr tools \(java or eiffel or else\) should be improved\. We need to organize some set of minimal test archetypes used for testing parsers\. I got some, and I am sure Thomas got some too\. But we need to centralize these test archetypes\. These are not the same as the clinical archetypes since they are just used for testing parsers \- don't need to be meaningful at all\. But they \_must\_ be complaint with the ADL specifications\! I am in the middle of re\-organizing the java components \(splitting them into even smaller pieces so they are more managable and reusable\)\. Cheers, Rong --- ## Post #27 by @system I must have missed the question, but it is "for all of us", so I better answer it\. I have the humble opinion that the software, which will give the concepts a home, \(it is not a house, it is a home\) need some improvement\. I will be happy to spend some time in that, best for me to do is programming\. We'll see were I can help, and when I have some time \(contrarily of some others, I, my children, my wife and my cat live for a part from software developing, so, working for money is important\) regards Bert Rong Chen schreef: --- ## Post #28 by @Sam Bert I think you have an older workbench - pre 1.4 Cheers, Sam Bert Verhees wrote: --- **Canonical:** https://discourse.openehr.org/t/archetype-editors/14570 **Original content:** https://discourse.openehr.org/t/archetype-editors/14570