# A toy Java "workbench" **Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154) **Created:** 2008-12-30 10:34 UTC **Views:** 1 **Replies:** 14 **URL:** https://discourse.openehr.org/t/a-toy-java-workbench/14867 --- ## Post #1 by @Olof_Torgersson1 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 --- ## Post #2 by @Tim_Cook2 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 --- ## Post #3 by @Adam_Flinton 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: --- ## Post #4 by @Seref 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 --- ## Post #5 by @Adam_Flinton 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\. >    Can be useful for understanding Adl > > \- Localized in English and Swedish\. > > The application can be downloaded from > > 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 --- ## Post #6 by @Adam_Flinton 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">         <xsl:param name="p\_pattern" />         <xsl:param name="p\_rootNode" />         <xsl:param name="p\_rm\_type\_name" />         <xsl:param name="debug" />                     <\!\-\- openEHR\-EHR\-CLASS\_NAME\\\.\(REGEX\_EXPRESSION\) \-\->     <\!\-\- When $p\_pattern contains $p\_rm\_type\_name assume it is a full regex     Else assume an \(old\) partial regex     \-\->     <xsl:variable name="v\_Dotpattern" >         <xsl:choose>             <xsl:when test="contains\($p\_pattern,$p\_rm\_type\_name\)">                 <xsl:message>                 ArchetypesMatchRegexPattern NEW STYLE                 </xsl:message>             <xsl:value\-of select="$p\_pattern" />             </xsl:when>             <xsl:otherwise>                 <xsl:message>                 ArchetypesMatchRegexPattern OLD STYLE                 </xsl:message>                 <xsl:value\-of select='concat\(normalize\-space\($p\_rm\_type\_name\),"\\\.\(",normalize\-space\($p\_pattern\),"\)"\)' />             </xsl:otherwise>     </xsl:choose>     </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 --- ## Post #7 by @Olof_Torgersson1 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: --- ## Post #8 by @thomas.beale Adam Flinton wrote: > ``` > 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 --- ## Post #9 by @Adam_Flinton 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 --- ## Post #10 by @thomas.beale Adam Flinton wrote: --- ## Post #11 by @thomas.beale Olof Torgersson wrote: --- ## Post #12 by @Olof_Torgersson1 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 [details="(attachments)"] [openEHR-EHR-CLUSTER.change.v1.adl|attachment](upload://a8JRm1I0mtAUSrdsJt8eLX8iOnK.adl) (273 Bytes) [/details] --- ## Post #13 by @thomas.beale 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: [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #14 by @Olof_Torgersson1 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: --- ## Post #15 by @thomas.beale 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: [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- **Canonical:** https://discourse.openehr.org/t/a-toy-java-workbench/14867 **Original content:** https://discourse.openehr.org/t/a-toy-java-workbench/14867