Archchetype editor on Linux --help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mattias Forss schreef: This message was send too early because of the foreign keyboard layout, excuse me for that, I will complete it now (please delete the previous) Thanks Mattias for your answer. I keep it short, now, the weather has improved, and I am on holiday ;-) and the keyboard-layout still is French, which causes me to search every character. Hi Bert, Sorry if this mail looks wierd, but I had to copy it from the mail archive on the openEHR website since I didn't get the mail for some wierd reason. I only got Erik's answer about publising the source code. Sometimes mails get lost when using the technical list and I don't know what's causing the problem. Anyway, I look forward to having more Java developers working on the editor and I hope it could improve the editor a lot more. Hopefully I can be inspired by other people's code and learn new things as well as come up with creative solutions. I doubt if you will learn many new things. But the product is very good and stable, and easy to handle. It showed me that it is possible to write responsive and stable interfaces in Java. That is a good thing. It will be of profit for the product to open source it. At this moment I am very busy on a very tight deadline, but it could well be possible in the near feature to work on the editor. The reason we haven't published the code is mainly that the code is not that good looking (it is actually quite ugly) in many places and I guess some people will have a hard time understanding the code, but good reasons to publish the code, I understand there is need for code improvement. As long as the object orientation is clear, code can be improved bit by bit. there are also pieces of the code which are rather good. The quality of the code may vary, but this is because we had limited time during the Master thesis project and we decided to implement as much functionality as possible instead of coding as neat as possible. This was probably because we felt the need to fully complete the editor for the final demonstration. When we started developing the pure Java-based archetype editor we decided to use some existing code from a Java archetype editor that was in development at the openEHR repository. This editor used a wrapped Eiffel parser and that is why it wasn't purely platform independant We used (and modified) parts of the code from the existing editor which was used as a facade against the openEHR archetype object model since that model is immutable. On the other hand, I don't think that this code is easy to understand even if you understand the API for the Java kernel. When we open source the code for the editor I suppose there might be questions if the facade code is worth using anymore or if it should be replaced with a better API that could be used as a facade for the archetype object model. I don't know what you mean in this, I think the best way to write a archetype editor is to directly use the java-kernel-code. I see some people want to rewrite the adl-parser, but, in fact the adl-parser is in its source quite clear and good. For me it is necessary to work also outside the reference model, but in ADL. It is a bit complicated to explain, Maybe read my previous mails. So I need a archetype-editor which loads ADL-files, and does not enforce or check the referene model. I translate HL7 XSD-files directly to ADL, that is to say, I am working on that, and the improvements give hope. The thing I miss is to viualize my ADL-files, so I have to check/debug them manually, which is hard. I could use the code of the archetype editor to change it for my needs, maybe it is not hard to do, but maybe it is, as I read about ugly code now. Except from my needs, which is at this moment, get a certain HL7 DMIM into ADL, I would think it is a good thing when a ADL-editor has a possibility for not to enforce the OpenEHR reference model. With all respect to the design of that model (clever people work hard on it. I sure want to follow that in the near future), I think it can be good if it is possible if people have good reasons to do something else with ADL, to facilitate that. So in this context, I think publishing the code will be very good. I hope it will be done in short time. regards Bert Verhees 2006/8/28, Bert Verhees bert.verhees at rosa.nl: There is already a Java-based archetype editor available here: http://svn.openehr.org/knowledge/archetypes/dev/index.html Too bad, the sourcecode still is not published (last time I downloaded it), I would like to see some improvements in (f.e.) error-handling. It does never say why I ADL-file cannot be loaded, it just says it cannot load it. There are many ADL-files, which it does not load, and I think for good reasons, but it should say why. If it had sourcecode with it, I would have repaired this, for my own use, because I have need for an
Archchetype editor on Linux --help
2006/9/2, Bert Verhees bert.verhees at rosa.nl: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mattias Forss schreef: We used (and modified) parts of the code from the existing editor which was used as a facade against the openEHR archetype object model since that model is immutable. On the other hand, I don't think that this code is easy to understand even if you understand the API for the Java kernel. When we open source the code for the editor I suppose there might be questions if the facade code is worth using anymore or if it should be replaced with a better API that could be used as a facade for the archetype object model. I don't know what you mean in this, I think the best way to write a archetype editor is to directly use the java-kernel-code. I see some people want to rewrite the adl-parser, but, in fact the adl-parser is in its source quite clear and good. We cannot use the kernel code directly unless we make changes to it to be mutable (changeable). The reason for this is because whenever you want to alter things, the Archetype object has to be rebuilt all over again because it is not allowed to be changed. Using the kernel code directly and rebuilding every time some small thing has changed would be very slow (especially very slow response in the GUI). However, I've heard of a new technique that could be used in Java to be able to do this a lot faster, but I'm not sure if it will solve all the problems in this case. For me it is necessary to work also outside the reference model, but in ADL. It is a bit complicated to explain, Maybe read my previous mails. So I need a archetype-editor which loads ADL-files, and does not enforce or check the referene model. I translate HL7 XSD-files directly to ADL, that is to say, I am working on that, and the improvements give hope. The thing I miss is to viualize my ADL-files, so I have to check/debug them manually, which is hard. I could use the code of the archetype editor to change it for my needs, maybe it is not hard to do, but maybe it is, as I read about ugly code now. This would require a feature in the editor to chose an unknown reference model (which you can give a name) and maybe also specify that reference model's semantics. It could be really messy working with unknown reference models, and hard to come up good ways to display things in a GUI. Since any rm type name can really constrain any data type (text, boolean, date) even things there aren't any corresponding controls for. I have almost finished implementing an ADL-editor, (in the formats view of the archetype editor) which could be used to edit whatever the parser accepts, but whenever the ADL is reloaded in the GUI, all things not corresponding to the openEHR RM (and things that aren't recognized as editable in the GUI) will disappear. I believe you could use this ADL-editor as a start, since it marks the line number that the parser fails on, but the downside is of course that you would have to do things manually. On the other hand, I don't think it's easy to create efficient GUIs for unknown reference models, since class and attribute names always have to be specified, unless of course one creates a really smart GUI that follows defined RM semantics which configures the widgets' functionality. Regards, Mattias Except from my needs, which is at this moment, get a certain HL7 DMIM into ADL, I would think it is a good thing when a ADL-editor has a possibility for not to enforce the OpenEHR reference model. With all respect to the design of that model (clever people work hard on it. I sure want to follow that in the near future), I think it can be good if it is possible if people have good reasons to do something else with ADL, to facilitate that. So in this context, I think publishing the code will be very good. I hope it will be done in short time. regards Bert Verhees 2006/8/28, Bert Verhees bert.verhees at rosa.nl: There is already a Java-based archetype editor available here: http://svn.openehr.org/knowledge/archetypes/dev/index.html Too bad, the sourcecode still is not published (last time I downloaded it), I would like to see some improvements in (f.e.) error-handling. It does never say why I ADL-file cannot be loaded, it just says it cannot load it. There are many ADL-files, which it does not load, and I think for good reasons, but it should say why. If it had sourcecode with it, I would have repaired this, for my own use, because I have need for an Archetype-editor which can also be used for debugging purposes. The source code will be published as open source in the future, but we at Link?ping university haven't decided when that will be. I think you probably know that publishing source-code in a early stage has advantages, this is specially true when one wants to publish it anyway. It allows others to implement features they need, and you can keep control
Archchetype editor on Linux --help
Thanks Mattias for your answer. I keep it short, now, the weather has improved, and I am on holiday ;-) and the keyboard-layout still is French, which causes me to search every character. 2006/8/28, Bert Verhees bert.verhees at rosa.nl: There is already a Java-based archetype editor available here: http://svn.openehr.org/knowledge/archetypes/dev/index.html Too bad, the sourcecode still is not published (last time I downloaded it), I would like to see some improvements in (f.e.) error-handling. It does never say why I ADL-file cannot be loaded, it just says it cannot load it. There are many ADL-files, which it does not load, and I think for good reasons, but it should say why. If it had sourcecode with it, I would have repaired this, for my own use, because I have need for an Archetype-editor which can also be used for debugging purposes. The source code will be published as open source in the future, but we at Link?ping university haven't decided when that will be. I think you probably know that publishing source-code in a early stage has advantages, this is specially true when one wants to publish it anyway. It allows others to implement features they need, and you can keep control by being the administrator of the CVS system, and hide forks you don't want. F.e. this is facilitated in sourceforge.net. This is why I don't understand that you do not publish the sourcecode now. But I am sure you(or the university) have good reasons for this. The current Java ADL-parser isn't complete yet and many archetypes are still badly formatted. The parser is not too forgiving, so for example if there are missing parts in the description part of an archetype the parsing process will fail. This is mainly why many ADL-files won't load. Also, when an archetype fails to load it is often due to parsing errors but we don't output the errors given by the parser because sometimes they don't make sense at all. However, I am thinking about adding error outputs from the parser to a logfile. This would be a good addition, and opening the logfile-window after failure, it could help someone to update older ADL-files which for now he has to update manually, and has no way to check in detail which small thing he forgot to change. As being a programmer I think, you know exactly what I mean. Another good feature I would like to see is two way editing, in a GUI and in ADL-editor, and see how changes on both sides reflect on the other side. And another feature is support for more ADL-versions, not only the latest. This could help migrate older ADL-files to newer versions. People who have invested in previous versions now have to dive into the (for some people) painful process of manually updating their ADL-files to newer versions. I have plans on making an ADL-editor that makes continuous checks as to whether the syntax is ok and marks the line number that the parser failed on, but this requires reloading of the edit buffer every time we want to show the changes in the GUI. It might become slow, but I believe it is possible to implement. However, there are many other things to implement before that, but it is definitely a good idea. You could an automatically reload replace by Older versions than 1.3 (I think) of ADL isn't supported which depends on the ADL parser but I guess it would be possible to implement support for different versions. However, this would require to implement support for that in the ADLSerializer as well and not to forget it would require a lot of checking to ensure that semantics and syntax of these archetypes are correct. However, I don't believe there is any idea of maintaining the older (ADL version 1.4) archetypes since they sometimes are inconsistent and faulty regarding to the reference model they are supposed to follow. I believe the current archetypes are the first ones that actually should be maintained since the openEHR project has suffered from teething troubles that are common to many large projects. At some point we must decide to migrate from older/obsolete versions even if it affects a lot of people, it is just a part of a natural evolution process for ADL. I am not saying the archetypes that have been used in older systems should be deleted, but there is no need creating more mess than needed. The older systems will eventually and inevitably have to start using newer archetypes in the future if they want to transfer and receive data to/from other clinical systems that haven't been around as long. So, except for not distributing the source-code, and to simple error-handling, it is a very stable and good tool. I expect the source-code to be published some day, because the creators indicated they will, but they did, as far as I know, not indicate when. The archetype editor from Ocean, which looks as GUI about the same as the Java-Archetype-editor, has sourcecode, and if you do not like dotnet-VB, you can
Archchetype editor on Linux --help
This message was send too early because of the foreign keyboard layout, excuse me for that, I will complete it now (please delete the previous) Thanks Mattias for your answer. I keep it short, now, the weather has improved, and I am on holiday ;-) and the keyboard-layout still is French, which causes me to search every character. 2006/8/28, Bert Verhees bert.verhees at rosa.nl: There is already a Java-based archetype editor available here: http://svn.openehr.org/knowledge/archetypes/dev/index.html Too bad, the sourcecode still is not published (last time I downloaded it), I would like to see some improvements in (f.e.) error-handling. It does never say why I ADL-file cannot be loaded, it just says it cannot load it. There are many ADL-files, which it does not load, and I think for good reasons, but it should say why. If it had sourcecode with it, I would have repaired this, for my own use, because I have need for an Archetype-editor which can also be used for debugging purposes. The source code will be published as open source in the future, but we at Link?ping university haven't decided when that will be. I think you probably know that publishing source-code in a early stage has advantages, this is specially true when one wants to publish it anyway. It allows others to implement features they need, and you can keep control by being the administrator of the CVS system, and hide forks you don't want. F.e. this is facilitated in sourceforge.net. This is why I don't understand that you do not publish the sourcecode now. But I am sure you(or the university) have good reasons for this. The current Java ADL-parser isn't complete yet and many archetypes are still badly formatted. The parser is not too forgiving, so for example if there are missing parts in the description part of an archetype the parsing process will fail. This is mainly why many ADL-files won't load. Also, when an archetype fails to load it is often due to parsing errors but we don't output the errors given by the parser because sometimes they don't make sense at all. However, I am thinking about adding error outputs from the parser to a logfile. This would be a good addition, and opening the logfile-window after failure, it could help someone to update older ADL-files which for now he has to update manually, and has no way to check in detail which small thing he forgot to change. As being a programmer I think, you know exactly what I mean. Another good feature I would like to see is two way editing, in a GUI and in ADL-editor, and see how changes on both sides reflect on the other side. And another feature is support for more ADL-versions, not only the latest. This could help migrate older ADL-files to newer versions. People who have invested in previous versions now have to dive into the (for some people) painful process of manually updating their ADL-files to newer versions. I have plans on making an ADL-editor that makes continuous checks as to whether the syntax is ok and marks the line number that the parser failed on, but this requires reloading of the edit buffer every time we want to show the changes in the GUI. It might become slow, but I believe it is possible to implement. However, there are many other things to implement before that, but it is definitely a good idea. You could an automatically reload replace by a reload-button. I think a kind of debugging facility would be a very good addition, and this I regard as a debugging facility, also lading files with errors in it is. Like Eclipse loads files with syntax errors in it. Which brings me to the following idea, I have read before in this list, creating a ADL-editor plugin for Eclipse. Older versions than 1.3 (I think) of ADL isn't supported which depends on the ADL parser but I guess it would be possible to implement support for different versions. However, this would require to implement support for that in the ADLSerializer as well and not to forget it would require a lot of checking to ensure that semantics and syntax of these archetypes are correct. Maybe it is not that hard, because you can use previous versions of the Java-implementations. But I agree, It would not be of much use, for the majority of users, but it could be of some use. Anyway, open sourcing it would give people a choice to implement it themselve. However, I don't believe there is any idea of maintaining the older (ADL version 1.4) archetypes since they sometimes are inconsistent and faulty regarding to the reference model they are supposed to follow. I believe the current archetypes are the first ones that actually should be maintained since the openEHR project has suffered from teething troubles that are common to many large projects. At some point we must decide to migrate from older/obsolete versions even if it affects a lot of people, it is just a part of a natural evolution process for ADL. Exactly that was my
Archchetype editor on Linux --help
On 8/28/06, Mattias Forss mattias.forss at gmail.com wrote: 2006/8/28, Bert Verhees bert.verhees at rosa.nl: There is already a Java-based archetype editor available here: http://svn.openehr.org/knowledge/archetypes/dev/index.html Too bad, the sourcecode still is not published [...] If it had sourcecode with it, I would have repaired this, for my own use, because I have need for an Archetype-editor which can also be used for debugging purposes. The source code will be published as open source in the future, but we at Link?ping university haven't decided when that will be. If there now are people that seriously want to contribute to the development with patches etc (like Bert suggests) I believe that it's time to publish the source very soon. We'll try to look in to this within a couple of weeks. Remind us if we forget it ;-) So there are two Archetype-Editors, both look about the same in GUI, but both are build on complete different technologies. And both need improvement. I think there is a need for more, specially if there are improvements on GUI-thinking. I know, all Word-processors look the same, and all cars look the same, but is it the best way a car or Word-processor should look? Your suggestions on improvements are always welcome... We do not know, so I suggest that someone who want to build an archetype-editor, should not look at those who exists, he could get trapped in obvious thinking. We had a lot of ideas when building the Java archetype editor concering the GUI, but eventually decided to design it like Ocean's GUI. There are a number of reasons we did this... Since it begun as a master thesis project I believe one of the main resasons for not inventing too many interface changes was the limited time available. Personally I am interested in information visualisation and usability and have several thoughts regarding possible interface alternatives. Time/resources still remain constraining factors so focus is on geting a somewhat complete editor first (and debugging/stabilising existing archetypes specifications underway). But feel free to experiment with and contribute alternative views as soon as we release the code. Best regards, Erik Sundvall (ex-supervisor of Mattias, but now a colleague) Currently at MIE in Maastricht -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060830/a639d998/attachment.html
Archchetype editor on Linux --help
There is already a Java-based archetype editor available here: http://svn.openehr.org/knowledge/archetypes/dev/index.html Regards, Mattias Forss 2006/8/27, minreddy minreddy minreddy at yahoo.com: Hello I'm thinking to port Archchetype editor to Linux. (As myself don't run windows at all) Are there any other dependencies other than ADL parser? (adl_java_lib.dll) Any help will be greatly appreciated! rgds minreddy -- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1?/min. http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://messenger.yahoo.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060828/a5a888f0/attachment.html
Archchetype editor on Linux --help
2006/8/28, Bert Verhees bert.verhees at rosa.nl: There is already a Java-based archetype editor available here: http://svn.openehr.org/knowledge/archetypes/dev/index.html Too bad, the sourcecode still is not published (last time I downloaded it), I would like to see some improvements in (f.e.) error-handling. It does never say why I ADL-file cannot be loaded, it just says it cannot load it. There are many ADL-files, which it does not load, and I think for good reasons, but it should say why. If it had sourcecode with it, I would have repaired this, for my own use, because I have need for an Archetype-editor which can also be used for debugging purposes. The source code will be published as open source in the future, but we at Link?ping university haven't decided when that will be. The current Java ADL-parser isn't complete yet and many archetypes are still badly formatted. The parser is not too forgiving, so for example if there are missing parts in the description part of an archetype the parsing process will fail. This is mainly why many ADL-files won't load. Also, when an archetype fails to load it is often due to parsing errors but we don't output the errors given by the parser because sometimes they don't make sense at all. However, I am thinking about adding error outputs from the parser to a logfile. Another good feature I would like to see is two way editing, in a GUI and in ADL-editor, and see how changes on both sides reflect on the other side. And another feature is support for more ADL-versions, not only the latest. This could help migrate older ADL-files to newer versions. People who have invested in previous versions now have to dive into the (for some people) painful process of manually updating their ADL-files to newer versions. I have plans on making an ADL-editor that makes continuous checks as to whether the syntax is ok and marks the line number that the parser failed on, but this requires reloading of the edit buffer every time we want to show the changes in the GUI. It might become slow, but I believe it is possible to implement. However, there are many other things to implement before that, but it is definitely a good idea. Older versions than 1.3 (I think) of ADL isn't supported which depends on the ADL parser but I guess it would be possible to implement support for different versions. However, this would require to implement support for that in the ADLSerializer as well and not to forget it would require a lot of checking to ensure that semantics and syntax of these archetypes are correct. However, I don't believe there is any idea of maintaining the older (ADL version 1.4) archetypes since they sometimes are inconsistent and faulty regarding to the reference model they are supposed to follow. I believe the current archetypes are the first ones that actually should be maintained since the openEHR project has suffered from teething troubles that are common to many large projects. At some point we must decide to migrate from older/obsolete versions even if it affects a lot of people, it is just a part of a natural evolution process for ADL. I am not saying the archetypes that have been used in older systems should be deleted, but there is no need creating more mess than needed. The older systems will eventually and inevitably have to start using newer archetypes in the future if they want to transfer and receive data to/from other clinical systems that haven't been around as long. So, except for not distributing the source-code, and to simple error-handling, it is a very stable and good tool. I expect the source-code to be published some day, because the creators indicated they will, but they did, as far as I know, not indicate when. The archetype editor from Ocean, which looks as GUI about the same as the Java-Archetype-editor, has sourcecode, and if you do not like dotnet-VB, you can still use it to extract useful parts of the architecture, and build your own in every language you want. The Ocean version has a few instabilities. So there are two Archetype-Editors, both look about the same in GUI, but both are build on complete different technologies. And both need improvement. I think there is a need for more, specially if there are improvements on GUI-thinking. I know, all Word-processors look the same, and all cars look the same, but is it the best way a car or Word-processor should look? Your suggestions on improvements are always welcome... We do not know, so I suggest that someone who want to build an archetype-editor, should not look at those who exists, he could get trapped in obvious thinking. We had a lot of ideas when building the Java archetype editor concering the GUI, but eventually decided to design it like Ocean's GUI. There are a number of reasons we did this, the most obvious was that we wanted to enable a structured overview of an archetype and this is why the different views in the editor was created. This
