# A toy Java "workbench"

**URL:** https://discourse.openehr.org/t/a-toy-java-workbench/14867
**Category:** Reference Implementation: Java (archive)
**Created:** [30 December 2008 10:34 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867 "2008-12-30T10:34:57Z")
**Posts on this page:** 15
**Page:** 1

<div class="post-metadata">

### Author: ![Olof\_Torgersson1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/o/3bc359/32.png) [@Olof\_Torgersson1](https://discourse.openehr.org/u/Olof_Torgersson1)
#### Post date: [30 December 2008 10:34 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/1 "2008-12-30T10:34:57Z")

</div>

Hi,

To learn more about openEHR programming and using the Java implementation, I’ve  
written what could be called a toy Java openEHR Workbench.

The feature list is not long but includes

- Possibility to view a tree presentation of an Archetype and the corresponding Adl or XML code at the same time.  
Can be useful for understanding Adl

- Localized in English and Swedish.

The application can be downloaded from

[http://www.medview.se/openehr](http://www.medview.se/openehr)

While very simple, the application is an example of something done using a Java implementation of openEHR.  
I’ve found very few such examples, it would be interesting to know about other projects going on.

Regards

Olof Torgersson

---

<div class="post-metadata">

### Author: ![Tim\_Cook2](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/57b2e6/32.png) [@Tim\_Cook2](https://discourse.openehr.org/u/Tim_Cook2)
#### Post date: [30 December 2008 20:23 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/2 "2008-12-30T20:23:40Z")

</div>

Hi Olof,

This is great to see this effort. The Python implementation of openEHR  
was started with a similar approach.

I always wanted to have something actually functional as I believe it  
will help attract others to using openEHR.

We started with a Python component architecture that is based on the  
Zope Application server. Of course this gives us many options as to  
HTTP/XML-RPC type services as well as persistence layers. But the point  
is to be able to provide some type of REAL application development  
environment that developers can work with to create future proof health  
care applications.

2009 is looking like a very good year for openEHR and it's various  
implementations.

Cheers,  
Tim

---

<div class="post-metadata">

### Author: ![Adam\_Flinton](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/b782af/32.png) [@Adam\_Flinton](https://discourse.openehr.org/u/Adam_Flinton)
#### Post date: [6 January 2009 10:52 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/3 "2009-01-06T10:52:10Z")

</div>

Entertaining that the example in the screenshot is one of our  
archetypes.....

Excellent....

I just hope that this means that the OSS Java tooling will keep up with  
the developments we are pushing through wrt problems we have found (e.g.  
wrt the regex'es used to locate archetypes from archetypes).

Adam

Olof Torgersson wrote:

---

<div class="post-metadata">

### Author: ![Seref](https://discourse.openehr.org/user_avatar/discourse.openehr.org/seref/32/13_2.png) [@Seref](https://discourse.openehr.org/u/Seref)
#### Post date: [6 January 2009 11:01 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/4 "2009-01-06T11:01:39Z")

</div>

Hi Adam,  
I would be very interested to hear about the problems you’ve identified. Would it be possible to get an overview of problems? For example, what is it that makes you consider use of regex’es as a problem? Is it a functional problem or a performance related issue? What are others, if there are any?  
I think having a list of issues/bugs etc regarding the java ref. impl and tooling would be very valuable. As far as I know there is no such list at the moment.

Kind Regards  
Seref

---

<div class="post-metadata">

### Author: ![Adam\_Flinton](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/b782af/32.png) [@Adam\_Flinton](https://discourse.openehr.org/u/Adam_Flinton)
#### Post date: [6 January 2009 11:11 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/5 "2009-01-06T11:11:39Z")

</div>

Olof Torgersson wrote:

> Hi,
> 
> To learn more about openEHR programming and using the Java  
> implementation, I've  
> written what could be called a toy Java openEHR Workbench.
> 
> The feature list is not long but includes
> 
> - Possibility to view a tree presentation of an Archetype and the  
> corresponding Adl or XML code at the same time.  
> &nbsp;&nbsp;&nbsp;Can be useful for understanding Adl
> 
> - Localized in English and Swedish.
> 
> The application can be downloaded from
> 
> [http://www.medview.se/openehr](http://www.medview.se/openehr)
> 
> While very simple, the application is an example of something done  
> using a Java implementation of openEHR.  
> I've found very few such examples, it would be interesting to know  
> about other projects going on.

BTW we have a very similar thing built using eclipse We will have to see  
if it can go up onto the OHT (Open Health Tools) site.

Adam

---

<div class="post-metadata">

### Author: ![Adam\_Flinton](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/b782af/32.png) [@Adam\_Flinton](https://discourse.openehr.org/u/Adam_Flinton)
#### Post date: [6 January 2009 12:54 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/6 "2009-01-06T12:54:37Z")

</div>

Seref Arikan wrote:

> Hi Adam,  
> I would be very interested to hear about the problems you've  
> identified. Would it be possible to get an overview of problems? For  
> example, what is it that makes you consider use of regex'es as a  
> problem? Is it a functional problem or a performance related issue?  
> What are others, if there are any?  
> I think having a list of issues/bugs etc regarding the java ref. impl  
> and tooling would be very valuable. As far as I know there is no such  
> list at the moment.

A) The problems are more at an archetype level per se.

It was to do with the regex in the archetype locators not being full  
regex'es i.e. no inclusion of the rm\_type name.

What it meant was that when ID'ing another archetype you had to go up to  
it's rm\_type name & then concat that with the regex etc to arrive at the  
"real" regex. Which was a bit of an annoyance. It is one of the things  
which is fixed in the nitrogen release.

We still have to support both sorts as once published we can not change  
final versions of anything so a partial XSLT listing :

\<xsl:template name="ArchetypesMatchRegexPattern"\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\<xsl:param name="p\_pattern" /\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\<xsl:param name="p\_rootNode" /\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\<xsl:param name="p\_rm\_type\_name" /\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\<xsl:param name="debug" /\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
&nbsp;&nbsp;&nbsp;&nbsp;\<!-- openEHR-EHR-CLASS\_NAME\.(REGEX\_EXPRESSION) --\>  
&nbsp;&nbsp;&nbsp;&nbsp;\<!-- When $p\_pattern contains $p\_rm\_type\_name assume it is a full regex  
&nbsp;&nbsp;&nbsp;&nbsp;Else assume an (old) partial regex  
&nbsp;&nbsp;&nbsp;&nbsp;--\>

&nbsp;&nbsp;&nbsp;&nbsp;\<xsl:variable name="v\_Dotpattern" \>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\<xsl:choose\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\<xsl:when test="contains($p\_pattern,$p\_rm\_type\_name)"\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\<xsl:message\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ArchetypesMatchRegexPattern NEW STYLE  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\</xsl:message\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\<xsl:value-of select="$p\_pattern" /\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\</xsl:when\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\<xsl:otherwise\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\<xsl:message\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ArchetypesMatchRegexPattern OLD STYLE  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\</xsl:message\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\<xsl:value-of  
select='concat(normalize-space($p\_rm\_type\_name),"\.(",normalize-space($p\_pattern),")")'  
/\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\</xsl:otherwise\>  
&nbsp;&nbsp;&nbsp;&nbsp;\</xsl:choose\>  
&nbsp;&nbsp;&nbsp;&nbsp;\</xsl:variable\>

B) However.....since you asked ....\<G\>

I created 2 ant tasks one using the Java Impl to create XML Archetypes  
from ADL & another using the Ocean Windows/.net code & it was  
interesting that some had some structures & others others & that the  
Java one seemed more exacting (e.g. erroring on a lack of an original  
author).

However my main problem was to do with the actual XML representation per  
se as in it's current form it is undiffable (I was looking to run both &  
then diff the 2 XML outputs from the same ADL). I.e. to work out that  
the java impl was creating some structures which the Ocean one wasn't I  
had to do a lot of "by eye" checking which is not very precise.

IMHO the Archetype XML format needs a deep level redo & this becomes  
painfully apparent when one tries using the newest Template tools as  
when you create operational templates the XML is perfectly OK at the  
template level but then it includes the relevant Archetype XML & the  
experience is jarring.

i.e. the current format is fine for creating an entire object but if one  
wants to use it as a deliverable (especially one where implementors will  
want to check over it looking for differences from a previous version)  
then.....

or indeed if one wants to use the Java ADL \> XML to check the .Net ADL \>  
XML or vice versa as (for example) there is no order of elements or sort  
order etc so the exact same object could be persisted to XML entirely  
correctly by 2 implementations & the XML would look entirely different  
(e.g. big structure A followed by big structure B in one impl vs the  
opposite in another & within each structure this same variability is  
then repeated).

It is a mindset change i.e "this is simply a persistence mechanism for  
an archetype object" vs "this is a document/deliverable which I will  
need to compare at a document level with other versions of this  
archetype at a document level".

i.e. given the same ADL I would expect identical XML outputs (identical  
in XML terms e.g attribute order might change) no matter what the engine  
was which created it.

Adam

---

<div class="post-metadata">

### Author: ![Olof\_Torgersson1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/o/3bc359/32.png) [@Olof\_Torgersson1](https://discourse.openehr.org/u/Olof_Torgersson1)
#### Post date: [6 January 2009 17:01 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/7 "2009-01-06T17:01:02Z")

</div>

Well I downloaded a number of archetypes from www.openehr/knowledge to use for testing.

It is clear that there are differences between implementations since there were archetypes that that  
could be parsed by Java that chrashed the openEHR Workbench and also the other way around.

There are also differences regarding ordering, i.e, the order in which subtrees appear in my tool and the openEHR workbench.

Regards

Olof

6 jan 2009 kl. 11.52 skrev Adam Flinton:

---

<div class="post-metadata">

### Author: ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [6 January 2009 17:29 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/8 "2009-01-06T17:29:14Z")

</div>

Adam Flinton wrote:

> ```auto
> Entertaining that the example in the screenshot is one of our
> archetypes.....
> 
> Excellent....
> 
> I just hope that this means that the OSS Java tooling will keep up with
> the developments we are pushing through wrt problems we have found (e.g.
> wrt the regex'es used to locate archetypes from archetypes).
> 
> ```

Hi Adam,

if you are referring to the truncated regexes in the Archetype Editor, this has been fixed quite some time ago, more or less according to your analysis, but I suspect you may not have the relevant tool release in the NHS yet.

- thomas beale

---

<div class="post-metadata">

### Author: ![Adam\_Flinton](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/b782af/32.png) [@Adam\_Flinton](https://discourse.openehr.org/u/Adam_Flinton)
#### Post date: [7 January 2009 12:59 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/9 "2009-01-07T12:59:41Z")

</div>

Olof Torgersson wrote:

> Well I downloaded a number of archetypes from www.openehr/knowledge to  
> use for testing.

I am fully in favour of people other than me testing tools against our  
archetypes \<G\>.

> It is clear that there are differences between implementations since  
> there were archetypes that that  
> could be parsed by Java that chrashed the openEHR Workbench and also  
> the other way around.

Yup.

> There are also differences regarding ordering, i.e, the order in which  
> subtrees appear in my tool and the openEHR workbench.

The ordering problem is what killed any attempt at xml diffing & makes  
comparing implementation A vs B very difficult.

Adam

---

<div class="post-metadata">

### Author: ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [7 January 2009 14:19 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/10 "2009-01-07T14:19:09Z")

</div>

Adam Flinton wrote:

---

<div class="post-metadata">

### Author: ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [7 January 2009 14:20 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/11 "2009-01-07T14:20:21Z")

</div>

Olof Torgersson wrote:

---

<div class="post-metadata">

### Author: ![Olof\_Torgersson1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/o/3bc359/32.png) [@Olof\_Torgersson1](https://discourse.openehr.org/u/Olof_Torgersson1)
#### Post date: [7 January 2009 16:00 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/12 "2009-01-07T16:00:15Z")

</div>

Hi,

According to the about-panel I use version 1.4.1.595. I downloaded and installed it December 6th 2008.

The problematic file was downloaded from www.openehr.org/knowledge October 30th and is called

openEHR-EHR-CLUSTER.change.v1.adl

I attach it to this mail, hope it works. Otherwise I can send it to you directly.

Regards

Olof

> **(attachments)**
>
> [openEHR-EHR-CLUSTER.change.v1.adl](https://discourse.openehr.org/404) (273 Bytes)

---

<div class="post-metadata">

### Author: ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [7 January 2009 17:55 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/13 "2009-01-07T17:55:33Z")

</div>

Olof,

I just realised that there was a stale link which is why you have this old version - I have fixed the download link on the website - now it points to the TRUNK version of the page at [http://www.openehr.org/svn/ref\_impl\_eiffel/TRUNK/apps/doc/adl\_workbench\_help.htm](http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/doc/adl_workbench_help.htm) Try downloading the 1.5.0 .exe (I am assuming you are on Windows; if not let me know, because I am not sure if the Mac OS or Linux builds are up to date).

- thomas beale

Olof Torgersson wrote:

> **(attachments)**
>
> ![OceanCsmall.png](https://discourse.openehr.org/images/transparent.png)

---

<div class="post-metadata">

### Author: ![Olof\_Torgersson1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/o/3bc359/32.png) [@Olof\_Torgersson1](https://discourse.openehr.org/u/Olof_Torgersson1)
#### Post date: [7 January 2009 19:53 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/14 "2009-01-07T19:53:12Z")

</div>

Thanks, I downloaded the latest specialisation build exe for windows.  
It still crashes on the change.v1-file though.  
Olof

7 jan 2009 kl. 18.55 skrev Thomas Beale:

---

<div class="post-metadata">

### Author: ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [10 January 2009 12:46 UTC](https://discourse.openehr.org/t/a-toy-java-workbench/14867/15 "2009-01-10T12:46:45Z")

</div>

Well done, you did find a bug - it is a path in that dADL serialiser code that has never been exercised - probably only specific to the Eiffel implementation. I fixed it, but it will be a little while before the fix is issued. The problem is that you have an empty ‘original\_author’ section. The Archetype Editor won’t let you do this - it needs to have something in it - have a look at some other archetypes and you can see example.

- thomas

Olof Torgersson wrote:

> **(attachments)**
>
> ![OceanCsmall.png](https://discourse.openehr.org/images/transparent.png)