Archetype-editors

Implementers (archive)
1

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:

2

2006/9/18, Bert Verhees <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

3

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

4

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

5

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

6

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

7

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.

8

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

9

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

10

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

11

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

12

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.

13

2006/9/18, Bert Verhees <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

14

2006/9/18, Bert Verhees <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
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

15

2006/9/18, Mattias Forss <mattias.forss@gmail.com>:

2006/9/18, Bert Verhees <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
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

16

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

17

Mattias Forss schreef:

2006/9/18, Bert Verhees <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
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?
:wink: just joking

regards
Bert Verhees

18

> 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

19

2006/9/19, Bert Verhees <bert.verhees@rosa.nl>:

Mattias Forss schreef:

2006/9/18, Bert Verhees <bert.verhees@rosa.nl
mailto:[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

20

2006/9/19, Rong Chen <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