Issues around UI technologies and bindings to back end
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
Issues around UI technologies and bindings to back end
Message: 1 Date: Sat, 25 Jul 2009 01:59:36 +0930 From: Heath Frankel heath.frankel at oceaninformatics.com Subject: RE: Issues around UI technologies and bindings to back end To: 'For openEHR technical discussions' openehr-technical at openehr.org Message-ID: 00db01ca0c7b$f05e67f0$d11b37d0$@frankel at oceaninformatics.com Content-Type: text/plain; charset=us-ascii 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 Generating XML from ADL is one piece - but what is needed is the schema definition and not the generic one that fits all archetypes but rather one that is specific to the data elements and content of each archetype. The technical people working with Archetypes today are obviously content with working with an ADL file but IMHO the software developers of tomorrow need to spend about 1 hour evaluating archetypes, import the definitions and then demonstrate that this well thought out, well structured OpenEHR data is of more value that defining ones own data hierarchy using HL7, LOINC, SNOMED etc. XML, XSD has orders of more tooling support, ADL only has the few tools available that we know of and that affects productivity. If XML/XSD became the defacto standard I could take our administrative and billing data model and convert into 'archetypes' and quickly people could begin to review them. As the CKM clinical reviews take place and the quality and quantity of the clinical archetypes increases the content becomes more valuable. But without easy access to that content I believe it does hamper adoption. -- 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/3ef081b8/attachment.html
Issues around UI technologies and bindings to back end
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090725/3575dcad/attachment.html
Issues around UI technologies and bindings to back end
yes - but to do this, they need to be working with templates. Archetypes on their own don't make sense as direct data-capture models. Thomas, I wonder why this is, maybe you can explain this or point to an explanation. Thanks Bert
Issues around UI technologies and bindings to back end
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090725/5d242ea7/attachment.html
