I have quite a few generated archetypes. Not clinically valid (or clinically validated at least) but they should be simple and varied enough to test. Or we could just try to generate a full cycle (I could open a CKM archetype, save it and give it back to you to test it).
2013/8/27 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 > > 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> > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130827/71601831/attachment-0001.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/71601831/attachment-0001.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/71601831/attachment-0001.jpg>
