Hi Thomas, thanks for your attention. I experienced the problems with the Ocean Archetype Editor and The LinkEhr editor when used in the same work-environment, for example, which causes archetypes to be opened in both editors.
It is not difficult to reproduce the errors and inconviences. The issue is that both, Ocean and LinkEhr, do not recognize their responsibility and do not see a need to change this. One problem easy to reproduce, easy, a few steps. - create an archetype in the LinkEhr editor, most simple, based on Element with one DataValue. You will see it will have a nodeid on the DataValue. - open it in the Ocean Editor, as I recall, this is not possible, first you need to change a few things, forgot what exactly. Small things, but this should not be. Ok, repair it in a text-editor, open it, and change one letter in the ontology, and save it. - The nodeids in the DataValue are removed without notifying the user. The archetype has changed on other places then was the purpose of the user. You can do this also the other way around and you will experience also problems. The solution is: a good behavior would be that an archetype editor would conform to the archetype a user loads in it, changing it without notification is very wrong. Another solution also needed would be that nodeids on locations where these are not enforced by the ADL-definition should be optional. These problems exist for years now, everyone knows about them, If it was my software, I would comfort my users and customers with friendly solutions. regards Bert Op dinsdag 27 augustus 2013 schreef Thomas Beale ( thomas.beale at oceaninformatics.com): > > Bert, > > I would be very happy to test some archetypes created with the LinkEHR > editor in the ADL workbench, but I don't think any are publicly visible are > they? We need some definitive problem reports to know what to fix. Or log > an issue here <http://www.openehr.org/issues/browse/AEPR>. > > I am pretty sure we can fix problems in both tools if we know what they > are. > > - thomas > > On 27/08/2013 19:44, Bert Verhees wrote: > > On 08/27/2013 07:20 PM, Diego Bosc? wrote: > > Do we need at-codes when > we create siblings such as DV_TEXT and DV_CODED_TEXT? > > In which circumstance can a sibling occur of a DataValue? Certainly not in > an ELEMENT. > I either cannot imagine another circumstance. > > So why use a node-value? Write a nodeId if you want, it is not very > interesting. The problem is another. > > It annoys me quite some time, this issue, not if you use a nodeId or not, > or if your archetype-editor does or does not. > > ***I would say, make it optional, configurable**** > > But what is the case? > > The problem is that there are two main archetype editors. > One creates nodeIds in DataValues, and the other does not. > The designers have apparently a different opinion on this. > > Sometimes the editors crash/choke on the ADL construct the other delivers. > And even when they do not choke, when you change one letter in an > archetype, maybe in the ontology.... > What happens? The editor quickly removes/adds the nodeIds on all > DataValues. (one does this, the other does that) > > This makes it impossible to work with them both. Ity makes it hard it > exchange archetypes with other people. > ------------------ > It looks very much alike the Document-format battle we have on this world > for years now, Word vs WordPerfect vs OpenOffice. Even ISO standards did > not solve this. > > Why is that? > What is behind this? > Competition? > ------------------ > Coming back to archetype editors? > Why change other parts of an archetype if someone wants to save a very > small change. > > I really gave up complaining about this, and I often use text-editors for > writing archetypes. At least, they do what I want them to do. > > So hey, we are living in 2013, it should not be that way. > > Please think about the users, the customers, do what they want you to do, > and make it configurable. All problems are solved then. > > Thanks > Bert > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org <javascript:_e({}, 'cvml', > 'openEHR-technical at lists.openehr.org');> > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > -- > [image: Ocean Informatics] <http://www.oceaninformatics.com/> *Thomas > Beale > Chief Technology Officer* > +44 7792 403 613 Specification Program, *open*EHR<http://www.openehr.org/> > Honorary Research Fellow, UCL <http://www.chime.ucl.ac.uk/> > Chartered IT Professional Fellow, BCS <http://www.bcs.org.uk/> > Health IT blog <http://wolandscat.net/category/health-informatics/> [image: > View Thomas Beale's profile on LinkedIn] > <http://uk.linkedin.com/in/thomasbeale> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130827/9d5a611f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: btn_liprofile_blue_80x15.png Type: image/png Size: 511 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130827/9d5a611f/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 4085 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130827/9d5a611f/attachment.jpg>
