gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] gehr gom and archetypes xsd files


From: sjtan
Subject: [Gnumed-devel] gehr gom and archetypes xsd files
Date: 28 Mar 2003 22:58:44 +1100


I think it may be possible to use the gehr.

Have a dynamic object like the apache commons DynaClass 
that can read a specification and then have properties according to
the specification.

I think python lets you do this even at a method level by interception
of __call__ or something like that.

The ideas is to parse the xsd files of gom into type definitions ,
perhaps an overall type dictionary. 

The problem is to add handlers for the different types , and whether
there needs to be handlers for types being referred at different parts
of the model. 

To make it more concrete, the xml parser generates python class files 
for the data types, and handler templates . (this is vague, I'm just
trying out an idea), much like what's been done for adding handlers to
the gui forms. Then manually add code for the handler function bodies.

On the other hand, manually translate the gom into python classes, and
by doing this, work out the processing for the gom that's involved.



Another problem is what form to store each element of a ehr -
relational, xml , or object database ? 
The EHR might change later, so the relational path , would require later
coding for dumping between an earlier database to a later database.
XML seems to be designed for change, so it might make it easier if data
is stored as xml e.g. perhaps as a text field in an relational object
database. 
   

On the surface, the gom looks similiar to what was written in Analysis
PAtterns by Fowler :


classes like Observation, Instruction, Process, Subjective, Proposition 
e.g. SOAP  s -> Subjective, O -> Observation, A -> Proposition, P ->
Instruction, Process 

The GOM has 2 EHR levels , level 1  which is A Record or a RecordExtract
and it 
acts as a collection for level 2 Transactions which contain Content ,
and the above SOAP are subclasses of Content.  Content also exhibit the
Composite Pattern, So a Content can  be a collection of contents or a 
leaf content. (presumably , though once a S  or a O composite , always
contains S or O , but not sure).


We could try to do a prototype with Hibernate to communicate to Postgres
but it would have to be in java; 
if there is an equivalent python open source Object Relational mapping 
middleware, maybe we could use that. (i.e. secifically, something that
maps composite objects onto relational tables).


There's good tutes of xml, xsd (which is XMLSchema)  at
        http://www.w3schools.com.
I thought DTD as a schema definition was easier to read, but all the
GOM is xsd files, (albeit 1999 instead of 2001 conforming), 
so I'm going through the XMLSchema tute.

I think we should be learning up the python xml libraries.

But as usual , no time !

 
 



















reply via email to

[Prev in Thread] Current Thread [Next in Thread]