Hi Randolph, I've commented between your lines. -- 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
Hi Pablo, I'm sorry for being so slow responding to your questions. I may not be understanding you fully, nor have I made myself totally clear to you. First, a DLL is a file system file known as a Dynamic Link Library, a unit of compiled machine-executable code, typically invoked from a computer code file with a .EXE extension or from another DLL file, with a .DLL file name extension. These naming conventions are used by Microsoft Windows programs, but may not be used by other platforms, which which I am unfamiliar. Of course, but in these context I rather prefer to give platform independent answers :D The ORM approach, as you describe it (correct me if I'm wrong), involves the creation of specific classes, expressed as compileable source code, and which therefore end up baked into the executable code files (EXE, DLL, or whatever the equivalent is called on your chosen platform). I am not sure how automated this process actually is in your OpenEHR context. Are you, for instance, able to download an archetype from the OpenEHR web site, press one button in your ORM, and thereby generate a class in your source code, which is then compiled into machine code (in something like a DLL)? And then, after that, with another push of a button, does a schema magically materialize, matching your auto-generated classes? If so, that's wonderful. Yes, you can download and configure and archetype in the system and the system will generate the GUI. We don't need to generate classes for these arcehtypes. The openEHR RM is implemented and it's persistent (I mean you don't need more classes than the RM, that's the point of using a reference model). The ORM persists the openEHR RM clases, and a binding component creates RM instances from user input data.So, there is no class generation and no compilation here.The schema is generated when you start the server, so all the process is automatic, and no need to generated or regenerate classes. The only thing that needs (re)generation is the GUI (just html files). But I have a concern that has nothing to do with automation, and which could actually be aggravated by automation. However automated the class or schema generation is or isn't, and no matter which process comes first (generating the classes or generating the schema), and no matter which process is dependent on the other, you still end up with both a schema and compiled code that will expand with each new class that you create. As I explained, that's not the case: no new code needed and no new schema generation needed to support new archetypes. Code and schemas are fixed. (don't take me wrong, I think you are attached to some technology or solution that is completely diferent of what we tried to implement). That's what I mean by "hard-wired." You can do a lot of hard-wired stuff very fast via ORM code or schema generation automation. Your DLLs (or whatever your equivalent is) will expand in size and number. Your schema will grow in size and complexity in direct proportion to the number of classes it is trying to persist. You don't feel the pain, however, because the computer did it all (or a lot of it) for you. Nope, no expansion of code here, only explansion of the config file and the knowledge base (archetypes and templates).You can see the code here: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn%2Ftrunk%2Fopen-ehr-gen But you're still left with an end product (consisting of schema and compiled code) that will bloat with each new thing it is designed to express, manage, present and store. That process can go on for a very long time, yes, but it can't go on forever. And the human body, with all the things that can go wrong with that body, ultimately requires thousands, maybe tens of thousands, of classes to describe just what can go wrong with the nervous system, to say nothing of the rest. It seems to me that the better solution would be to develop a metadata-based system capable of describing all that must be expressed, allowing both schema and program code to remain unchanged while presenting to the user information of which the compiled code and schema are both essentially ignorant. In other words, neither the program code nor your schema has any awareness of particular structures of medical information. All of that is instead in the metadata, not schema, in the metadata, not classes. That's exactly what we have done! :DI'm sorry if I didn't explain it correctly. The design is based on this principle: none dependency to custom domain information on the system backend, that dependency is only on the GUI side (the only thing we need to generate). My mistake in all this may be that I am mentally associating "classes" with source code that ends up as compiled code, but maybe you mean something else by your OOP terminology, something more akin to metadata that never gets baked in to the machine code. But I don't think I've misunderstood your concept of a schema. I had all along thought that OpenEHR was intended to operate in precisely the way I have described, as a basis for expressing complex information with simple schema and source code, neither of which embody, in hard-wired form, particular medical information structures. Your description of ORM seems to me to mean something else. If I'm wrong, I certainly apologize. Thanks, Randy Neall -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120222/0cb98ad8/attachment.html>
