Pablo, OK, what you say is reassuring. One of the things I had admired about OpenEHR was what I thought you were violating with ORM, which, in many contexts does exactly what I described, but evidently not in yours.
>The schema is generated when you start the server, so all the process is automatic, and no need to generated or regenerate classes. I don't quite understand why a schema would be generated when the server starts if the schema does not change relative to domain-specific content. But this is a minor point, something I don't need to understand. Also, your "classes" are themselves apparently quite abstract, allowing all kinds of content to be housed in them, thus reducing the number of classes to some maneagable number. Am I correct that GUI generation, the one thing you say you do generate, is simply a matter of generating html? Thanks very much! Randy Neall On Wed, Feb 22, 2012 at 11:18 AM, pablo pazos <pazospablo at hotmail.com>wrote: > 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 <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! :D* > I'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 > > _______________________________________________ > 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/20120222/13ade20e/attachment.html>
