openEHR Transition: Web-based tools?
Seref Arikan wrote: ... Unfortunately, most modern software development technologies arrive with their own runtimes, (.net framework, jre etc) and it quickly becomes a nightmare to deploy and update software. I'm not aware of any such deployment problems with .NET. I'm sure there must be some, somewhere, but they must be edge cases. In ten years of .NET development I haven't bumped into them. Different versions of .NET sit side-by-side on the same machine just fine; ditto for DLLs targeted towards different .NET versions. My daily work involves a .NET 4.0 application that has dependencies on a lot of .NET 2.0 DLLs; it just works seamlessly. - Peter
openEHR Transition: Web-based tools?
Hi all, Both approaches have their pros and cons. I would suggest a hybrid approach. Have a desktop app with a local Db that updates itself from a web based repository, as per need. This way you could have the security and speed of a desktop app with the 'updatability' of a web model. With warm regards, Dr D Lavanian MBBS,MD CEO and MD HCIT Consultant www.hcitconsultant.com Visit www.medhelp247.com for a life saving medical service Certified HL7 Specialist Executive Member - IAMI Co-Chair, Memberships - HL7 India Member- American Medical Informatics Association Member HIMSS Senior Consultant and Domain Expert - Healthcare Informatics and TeleHealth Former Vice President - Healthcare Products, Bilcare Ltd Former Vice President - Software Division, AxSys Healthtech Ltd Former Co-convener Sub committee on Standards , Governmental Task force for Telemedicine Former Vice President - Telemedicine (Technical), Apollo Hospitals Group Former Deputy Director Medical Services, Indian Air Force Office: +91 20 32345045 Mobile: +91-9970921266 - Original Message - From: pablo pazos To: openehr technical Sent: Saturday, September 10, 2011 11:01 PM Subject: RE: openEHR Transition: Web-based tools? Hi Ian, We develop web based systems because we are web developers. In my case I have started my programming skills on web based systems, and now I have learned a lot of tools, frameworks and web standards and I have very little experience on desktop based tools. Said that, I think desktop based tools have the same value and usability as the web based ones. There are tools that by nature have to be web based, but other tools like the template editor is ok on desktop. I have the dream that one day I open just one program (a web browser) and get free access to all the archetypes and templates available in the cloud (multiple CKMs), and may create, edit and share those artefacts also online. Sometimes I think about something like an openEHR facebook, where archetypes are people, templates are groups, and all are related by slots (friend relationships). This is just a dream... -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: Ian.McNicoll at oceaninformatics.com Date: Fri, 9 Sep 2011 16:10:10 +0100 Subject: openEHR Transition: Web-based tools? To: openehr-technical at openehr.org Hi all, One of the suggestions in the White Paper which appears to have universal support is a move to support much more open-source tools development. Clearly some tooling must be web-based e.g repository management and associated formal and informal discussion e.g. CKM and any new community repository. However, I am much less clear on why we might need web-based primary authoring tools for archetypes and templates. Diego, Pablo and Sam are all keen on this approach but I remain unconvinced that this is really a key requirement, given that archetype authoring is in essence a solitary activity much like any other code development. By all means build in much better integration with repositories and other mechanisms to allow joint working, but even with modern javascript libraries and Flex-style components, HTML-based tooling just feels like it adds a layer of development complexity and probably some usability-clunkiness which is not offset by the benefits. Maybe I am just an old-timer but having waited for may years to get the kind of development environment that Visual Studio, Eclipse and equivalents bring, and that I think is equally required for archetype development, I am loathe for us to get slowed-down by insisting on a 'web-based'. What do others think? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110911/00920c18/attachment.html
openEHR Transition: Web-based tools?
Hi Dr Lavinian, That was what I had in mind, absolutely integrate with repositories via web-services. I could be persuaded by a full web-based tool if someone could convince that me that difficulties of developing a complex UI are offset by other advantages, that it can operate off-line, that it can quickly implement no-cost, multiple temporary working areas, fully integrate with my other desktop applications and not get mangled by browser updates. I am not at all convinced by the deployment/update argument for web-based tools. It really is not at all difficult to manage packaged downloadable installs, including slip-streamed updates with notifications. I have done this myself with as one developer, 3000 users and a decent install program Perhaps the java environment is harder but my consumer experience of Eclipse and other java apps is not one of horrible complexity. Whilst seamless automatic updating of a web-app is generally helpful, there are situations where such updating conflicts with user wishes, so you end up having to replicate an upgrade only on-demand facility as per Google mail, or 'revert to older version'. But for me the UI issue is critical. I know that javascript and HTML5 developments are improving things all the time but web-based apps are still always more clunky and prone to weirdnesses that you simply do not see with desktop apps. As Seref says this is not the place to document actual UI requirements but I think it is fair to position an archetype/template tool with the UI demands of an Eclipse/VS type application, and as THomas says, no-one is using web apps for this kind of scenario. Pablo - is your web-based template tool visible anywhere? Perhaps you could persuade me that I ma wrong :-) Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 11 September 2011 02:25, Dr Lavanian lavanian at vsnl.net wrote: Hi all, Both approaches have their pros and cons. I would suggest a hybrid approach. Have a desktop app with a local Db that updates itself from a web? based repository, as per need. This way you could have the security and speed of a desktop app with the?'updatability' of a web model. With warm regards, Dr D Lavanian MBBS,MD CEO and MD HCIT Consultant www.hcitconsultant.com Visit www.medhelp247.com for a life saving medical service Certified HL7 Specialist Executive Member - IAMI Co-Chair, Memberships - HL7 India Member- American Medical Informatics Association Member HIMSS Senior Consultant and Domain Expert - Healthcare Informatics and TeleHealth Former Vice President - Healthcare Products, Bilcare Ltd Former Vice President - Software Division, AxSys Healthtech Ltd Former Co-convener Sub committee on Standards , Governmental Task force for Telemedicine Former Vice President - Telemedicine (Technical), Apollo Hospitals Group Former Deputy Director Medical Services, Indian Air Force Office: +91 20 32345045 Mobile: +91-9970921266 - Original Message - From: pablo pazos To: openehr technical Sent: Saturday, September 10, 2011 11:01 PM Subject: RE: openEHR Transition: Web-based tools? Hi Ian, We develop web based systems because we are web developers. In my case I have started my programming skills on web based systems, and now I have learned a lot of tools, frameworks and web standards and I have very little experience on desktop based tools. Said that, I think desktop based tools have the same value and usability as the web based ones. There are tools that by nature have to be web based, but other tools like the template editor is ok on desktop. I have the dream that one day I open just one program (a web browser) and get free access to all the archetypes and templates available in the cloud (multiple CKMs), and may create, edit and share those artefacts also online. Sometimes I think about something like an openEHR facebook, where archetypes are people, templates are groups, and all are related by slots (friend relationships). This is just a dream... -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: Ian.McNicoll at oceaninformatics.com Date: Fri, 9 Sep 2011 16:10:10 +0100 Subject: openEHR Transition: Web-based tools? To: openehr-technical at openehr.org Hi all, One of the suggestions in the White Paper which appears to have universal support is a move to support much more open-source tools development. Clearly some tooling must be web-based e.g repository management and associated formal and informal discussion e.g. CKM and any new community repository.
openEHR Transition: Web-based tools?
Peter, The problem is not necessarily about the capability of frameworks to manage updates or side by side execution. 90% of the time problem is about the IT policies of the institutions. If you develop with .NET 4.0, which would require a .net framework 4.0 runtime, you assume that the people using the software would be able to install the runtime, and install the software. many corporate/institutional machines do not allow their users install software. Most of the corporate/institutional IT is running on horribly old software. IT policy is the real issue I was referring to. I don't want to go into a long description of things that went wrong for me in the past, but let me just say that I've personally had enough issues with both Java and .NET deployment and upgrades that makes web based apps a much better option when it comes to this particular aspect of software life cycle. Regards Seref On Sat, Sep 10, 2011 at 2:18 PM, Peter Gummer peter.gummer at oceaninformatics.com wrote: Seref Arikan wrote: ... ?Unfortunately, most modern software development technologies arrive with their own runtimes, (.net framework, jre etc) and it quickly becomes a nightmare to deploy and update software. I'm not aware of any such deployment problems with .NET. I'm sure there must be some, somewhere, but they must be edge cases. In ten years of .NET development I haven't bumped into them. Different versions of .NET sit side-by-side on the same machine just fine; ditto for DLLs targeted towards different .NET versions. My daily work involves a .NET 4.0 application that has dependencies on a lot of .NET 2.0 DLLs; it just works seamlessly. - Peter ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
openEHR Transition: Web-based tools?
Hi Seref, I accept that , but you can say exactly the same thing about browsers and web connectivity generally. Until very recently the NHS in the UK mandated IE6 - go figure. How long before we see snazzy new HTML5 browsers in these environments? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 11 September 2011 11:21, Seref Arikan serefarikan at kurumsalteknoloji.com wrote: Peter, The problem is not necessarily about the capability of frameworks to manage updates or side by side execution. 90% of the time problem is about the IT policies of the institutions. If you develop with .NET 4.0, which would require a .net framework 4.0 runtime, you assume that the people using the software would be able to install the runtime, and install the software. many corporate/institutional machines do not allow their users install software. Most of the corporate/institutional IT is running on horribly old software. IT policy is the real issue I was referring to. I don't want to go into a long description of things that went wrong for me in the past, but let me just say that I've personally had enough issues with both Java and .NET deployment and upgrades that makes web based apps a much better option when it comes to this particular aspect of software life cycle. Regards Seref On Sat, Sep 10, 2011 at 2:18 PM, Peter Gummer peter.gummer at oceaninformatics.com wrote: Seref Arikan wrote: ... ?Unfortunately, most modern software development technologies arrive with their own runtimes, (.net framework, jre etc) and it quickly becomes a nightmare to deploy and update software. I'm not aware of any such deployment problems with .NET. I'm sure there must be some, somewhere, but they must be edge cases. In ten years of .NET development I haven't bumped into them. Different versions of .NET sit side-by-side on the same machine just fine; ditto for DLLs targeted towards different .NET versions. My daily work involves a .NET 4.0 application that has dependencies on a lot of .NET 2.0 DLLs; it just works seamlessly. - Peter ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
openEHR Transition: Web-based tools?
Seref Arikan wrote: 90% of the time problem is about the IT policies of the institutions. If you develop with .NET 4.0, which would require a .net framework 4.0 runtime, you assume that the people using the software would be able to install the runtime, and install the software. Yes, that's a problem I have run into once or twice. It's the perfect argument for developing Eiffel native executables. The problem then, of course, is that support may be less than perfect for the system that you want to run the application on. Getting behind the effort to get Eiffel running better on those platforms would be the quickest and most effective way to go, in my opinion. ... web based apps a much better option when it comes to this particular aspect of software life cycle. But web based apps bring their own set of problems that desktop apps don't have. Ian has been talking about poor usability. * How do you do keyboard shortcuts in a web application? How do you set keyboard focus to the appropriate widget to maximise ease of use? Both of those can be achieved in a web app, but it's extremely difficult. * How do you recover gracefully when the user's session times out? Imagine you're in the middle of working on an archetype, you spend 20 minutes talking to a colleague or answering emails, and your web session times out. All of your work is gone. There are ways to handle this gracefully, but they are are horribly difficult to program. This problem simply doesn't exist with desktop apps. * How do you design your application so that it performs well without putting half of your business logic into Javascript that is riddled with hacks for handling old browsers? - Peter
openEHR Transition: Web-based tools?
Hi! I agree with Seref. Web based apps nowadays can use local storage in modern web clients and even be run perfectly offline and sync when they get back online. If effort is put into new tools it might be good idea to do at least the GUI in HTML5 etc. The server could be any technology you want, including Eiffel ;-), as long as it speaks http, if normal users (including ones under IT policies of the institutions) don't need to do a server install. Regarding editing power and repository integration have a look at some examples like http://c9.io/ http://ace.ajax.org/ By the way, using Git as archetype repository sync backend at least for non-CKM work (as hinted by Shinji) seems to be a really nice idea the nore you look at it. The Git collaboration patterns and mentality seem to fit the use-case of distributed multi-branched archetype development. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 On Sun, Sep 11, 2011 at 12:21, Seref Arikan serefarikan at kurumsalteknoloji.com wrote: Peter, The problem is not necessarily about the capability of frameworks to manage updates or side by side execution. 90% of the time problem is about the IT policies of the institutions. If you develop with .NET 4.0, which would require a .net framework 4.0 runtime, you assume that the people using the software would be able to install the runtime, and install the software. many corporate/institutional machines do not allow their users install software. Most of the corporate/institutional IT is running on horribly old software. IT policy is the real issue I was referring to. I don't want to go into a long description of things that went wrong for me in the past, but let me just say that I've personally had enough issues with both Java and .NET deployment and upgrades that makes web based apps a much better option when it comes to this particular aspect of software life cycle. Regards Seref On Sat, Sep 10, 2011 at 2:18 PM, Peter Gummer peter.gummer at oceaninformatics.com wrote: Seref Arikan wrote: ... ?Unfortunately, most modern software development technologies arrive with their own runtimes, (.net framework, jre etc) and it quickly becomes a nightmare to deploy and update software. I'm not aware of any such deployment problems with .NET. I'm sure there must be some, somewhere, but they must be edge cases. In ten years of .NET development I haven't bumped into them. Different versions of .NET sit side-by-side on the same machine just fine; ditto for DLLs targeted towards different .NET versions. My daily work involves a .NET 4.0 application that has dependencies on a lot of .NET 2.0 DLLs; it just works seamlessly. - Peter
openEHR Transition: Web-based tools?
I have still not seen anything that looks remotely like a modern IDE This looks like state of the art ... A look at Eclipse' new browser-based web development tool, Orion http://www.youtube.com/watch?v=yA_lsvKfv4I I remain unimpressed (in terms of what we might require) but happy to be pointed to a real, working example of a web-development tool which might replace and considerably augment current archetype editor, template designer functionality, without requiring some really arcane web-developer skills. What we should really do now is to establish the requirements for this second generation of tools. I am certain web-services will play a big part in repository integration and e.g validation/comparison services but still not convinced that the kind of rich GUI we require is deliverable quickly with HTML. Thanks all. Interesting discussion :-) Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 11 September 2011 14:23, Erik Sundvall erik.sundvall at liu.se wrote: Hi! I agree with Seref. Web based apps nowadays can use local storage in modern web clients and even be run perfectly offline and sync when they get back online. If effort is put into new tools it might be good idea to do at least the GUI in HTML5 etc. The server could be any technology you want, including Eiffel ;-), as long as it speaks http, if normal users (including ones under IT policies of the institutions) don't need to do a server install. Regarding editing power and repository integration have a look at some examples like http://c9.io/ http://ace.ajax.org/ By the way, using Git as archetype repository sync backend at least for non-CKM work (as hinted by Shinji) seems to be a really nice idea the nore you look at it. The Git collaboration patterns and mentality seem to fit the use-case of distributed multi-branched archetype development. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 On Sun, Sep 11, 2011 at 12:21, Seref Arikan serefarikan at kurumsalteknoloji.com wrote: Peter, The problem is not necessarily about the capability of frameworks to manage updates or side by side execution. 90% of the time problem is about the IT policies of the institutions. If you develop with .NET 4.0, which would require a .net framework 4.0 runtime, you assume that the people using the software would be able to install the runtime, and install the software. many corporate/institutional machines do not allow their users install software. Most of the corporate/institutional IT is running on horribly old software. IT policy is the real issue I was referring to. I don't want to go into a long description of things that went wrong for me in the past, but let me just say that I've personally had enough issues with both Java and .NET deployment and upgrades that makes web based apps a much better option when it comes to this particular aspect of software life cycle. Regards Seref On Sat, Sep 10, 2011 at 2:18 PM, Peter Gummer peter.gummer at oceaninformatics.com wrote: Seref Arikan wrote: ... ?Unfortunately, most modern software development technologies arrive with their own runtimes, (.net framework, jre etc) and it quickly becomes a nightmare to deploy and update software. I'm not aware of any such deployment problems with .NET. I'm sure there must be some, somewhere, but they must be edge cases. In ten years of .NET development I haven't bumped into them. Different versions of .NET sit side-by-side on the same machine just fine; ditto for DLLs targeted towards different .NET versions. My daily work involves a .NET 4.0 application that has dependencies on a lot of .NET 2.0 DLLs; it just works seamlessly. - Peter ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
openEHR Transition: Web-based tools?
and web standards and I have very little experience on desktop based tools. Said that, I think desktop based tools have the same value and usability as the web based ones. There are tools that by nature have to be web based, but other tools like the template editor is ok on desktop. I have the dream that one day I open just one program (a web browser) and get free access to all the archetypes and templates available in the cloud (multiple CKMs), and may create, edit and share those artefacts also online. Sometimes I think about something like an openEHR facebook, where archetypes are people, templates are groups, and all are related by slots (friend relationships). This is just a dream... -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: Ian.McNicoll at oceaninformatics.com Date: Fri, 9 Sep 2011 16:10:10 +0100 Subject: openEHR Transition: Web-based tools? To: openehr-technical at openehr.org Hi all, One of the suggestions in the White Paper which appears to have universal support is a move to support much more open-source tools development. Clearly some tooling must be web-based e.g repository management and associated formal and informal discussion e.g. CKM and any new community repository. However, I am much less clear on why we might need web-based primary authoring tools for archetypes and templates. Diego, Pablo and Sam are all keen on this approach but I remain unconvinced that this is really a key requirement, given that archetype authoring is in essence a solitary activity much like any other code development. By all means build in much better integration with repositories and other mechanisms to allow joint working, but even with modern javascript libraries and Flex-style components, HTML-based tooling just feels like it adds a layer of development complexity and probably some usability-clunkiness which is not offset by the benefits. Maybe I am just an old-timer but having waited for may years to get the kind of development environment that Visual Studio, Eclipse and equivalents bring, and that I think is equally required for archetype development, I am loathe for us to get slowed-down by insisting on a 'web-based'. What do others think? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110911/f53a7f89/attachment.html
openEHR Transition: Web-based tools?
Hi Peter, Web developers can easily tackle those problems, see below: But web based apps bring their own set of problems that desktop apps don't have. Ian has been talking about poor usability. * How do you do keyboard shortcuts in a web application? How do you set keyboard focus to the appropriate widget to maximise ease of use? Both of those can be achieved in a web app, but it's extremely difficult. Just use HTML: http://en.wikipedia.org/wiki/Access_key * How do you recover gracefully when the user's session times out? Imagine you're in the middle of working on an archetype, you spend 20 minutes talking to a colleague or answering emails, and your web session times out. All of your work is gone. There are ways to handle this gracefully, but they are are horribly difficult to program. This problem simply doesn't exist with desktop apps. One way to maintain a session open is to send heartbeats using AJAX: http://en.wikipedia.org/wiki/Ajax_%28programming%29 * How do you design your application so that it performs well without putting half of your business logic into Javascript that is riddled with hacks for handling old browsers? For performance and rich user interaction we have to use AJAX. For compatibility, use standards: http://www.w3.org/ -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110911/c173aafd/attachment.html
EN/ISO 13606 openEHR - harmonisation possibilities
-Original Message- From: Diego Bosc? yamp...@gmail.com Sender: openehr-technical-bounces at openehr.org openehr-technical-bounces at openehr.org Date: Sat, 10 Sep 2011 09:45:17 To: For openEHR technical discussionsopenehr-technical at openehr.org Reply-To: For openEHR technical discussions openehr-technical at openehr.org Subject: Re: EN/ISO 13606 openEHR - harmonisation possibilities yes, what I mean is attributes like ID or even invalid characters in the names (like ':'). This is a problem with the parser (and also with classes identifiers) 2011/9/10 Thomas Beale thomas.beale at oceaninformatics.com: On 10/09/2011 12:59, Diego Bosc? wrote: This kind of problems has given us a lot of problems when using ADL to work with other models like HL7 CDA or CDISC ODM, where there isn't any kind of rule (for example, in ADL CLASSES must be upercase and the attributes lowercase, and in CDA this is not true) actually there is no rule in ADL. You can use CamelCase, and it has been working for the entire lifetime of the tools. Indeed you will see it in the 13606 and 21090 schemas, which are processed by the ADL Workbench. It's just that the documents use a particular convention which happens to be the underscore convention, for better readability. My view is that any given model should stick to one or the or the convention consistently, whatever convention that may be. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical La informaci?n contenida en el presente correo es privada y confidencial entre las partes y su uso, copia, reproducci?n o distribuci?n est? expresamente prohibida.
