There is an open source ADL to XML conversion library for .NET written in c#
located at
http://www.openehr.org/svn/knowledge_tools_dotnet/RELEASES/BlueChina/XMLPars
er.  This is used by the Archetype Editor to generate a pure XML
representation of the ADL file via the ADL_Parser so that it can create a
canonical xml representation of the archetype model for hashing purposes.
The XML displayed and files generated directly from the Archetype Editor
uses a different (legacy) mechanism and is not as reliable as that produced
by the conversion library, the result is slightly different XML output.  We
just have not had enough volunteer time to replace this legacy approach
within the Archetype Editor.  

 

If anyone need assistance in using this conversion library I can provide an
NUnit test library that shows how it can be used, or you can sift through
the Archetype Editor code if you prefer VB.

 

We actually have a publishing tool using this library that can run a batch
process against an entire Archetype file repository that can be run within
an auto-build process and committed back into svn.  This is how the XML
archetypes on openEHR used to get generated prior to CKM.

  

I am not sure if CKM supports XML output of archetypes as yet but if it is
felt that not having archetypes available in XML is holding back openEHR
adoption then I am sure this can be put on the change request list for
prioritisation.

 

 

Regards

 

Heath

 

Heath Frankel

Product Development Manager

Ocean Informatics

 

heath.frankel at oceaninformatics.com

+61 (0) 8 7127 5574 

 

Regards

 

Heath

 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Greg Caulton
Sent: Thursday, 23 July 2009 8:45 PM
To: openehr-technical at openehr.org
Subject: Re: Issues around UI technologies and bindings to back end

 

 

Date: Wed, 22 Jul 2009 15:16:20 +0200
From: hepabolu <hepab...@gmail.com>
Subject: Re: Issues around UI technologies and bindings to back end
To: For openEHR technical discussions <openehr-technical at openehr.org>
Message-ID: <4A671124.7020002 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Seref Arikan said the following on 22/7/09 11:39:
> Now about UI - model relationship, my view is the GUI layer is way too
> complex and diverse to include in openEHR specifications, even a subset
> of the UI related stuff would be enough to introduce more problems than
> it solves.
> IF there emerges a cross platform AND cross technology declerative
> markup for GUI and GUI interactions and bindings, and this is a big if,
> then it may be considered, otherwise, my personal opinion is to simply



I agree, to start integrating UI related content into the archetypes is a
very bad idea.

Most modern UIs follow a Model-View-Controller
<http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller>
approach.  For PatientOS Archetypes provide the data elements.  The
relationships and constraints within the archetype data elements is
implemented in our model.  We have different views - fat client, web client
which are implemented through controllers written in java or javascript.

Atttempts to push everything into the archetype definition would create a
complex beast which would defeat KISS principal.

As a side note I also think the ADL files is hampering adoption - not for us
as there is a Java parser.  Since everything that is the ADL must be
expressable in XML (otherwise interoperability of the definitions would be
problematic) - why have both - XML is ubiquitous and I think the benefits of
readibility of an ADL file is no longer needed since there are tools which
replace it - how many people read an ADL file any more? 


-- 
Gregory Caulton
Principal at PatientOS Inc.
personal email: caultonpos at gmail.com
http://www.patientos.com
corporate: (888)-NBR-1EMR || fax  857.241.3022

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090725/3ad435d6/attachment.html>

Reply via email to