gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] some more experimental stuff.


From: syan tan
Subject: [Gnumed-devel] some more experimental stuff.
Date: Sun, 26 Nov 2006 00:49:07 +1100

there is another schema walking tool in test-area/sjtan/schemascan2.py
which at the moment is generating a compact relax_ng schema out of
a walk over the gnumed schema. 
  Starting with identity, it walks
parent-child (one-to-many) first, then many-to-one for selected 
tables ( such as those beginning with lnk_*) ,
and then it does a cleanup both-ways walk on some specified nodes.
        It runs through a configuration file, although some of
it may need to be moved to the configuration file (like looking 
at lnk_ tables in the second phase ).

        
After that it generates a compact relax_ng schema ;
  I chose compact relax_ng schema because it had the most understandable
tutorial on google ; it was a pity the yaml spec was a bit too
action-packed with graphics, but I couldn't find the schema stuff
quick enough.
   I'd like the schema walker to be able to parse a directory of xbase
tables, given some configuration, and latter maybe data transformation
can be made semi-automatic/ configured.  It might even be possible
to have a "leach mode" with gnumed running beside a legacy application's
database
whose schema can be transformed to gnumed, and when first opening 
a record, it is leached into gnumed ; sort of import over a very
long time.
 

Another experiment, is to mark certain sections of the document
to be available for display and possibly editing in a semi-automated
way, e.g. maybe its possible to have generators for some kinds of
gui cliches , e.g. the browse list, edit panel, read only panel combo,
readonly lists from different sections on a summary tab, but
separate editor/browse tabs for each section; more than one
editor/browse tab arranged in a row or column for related sections
with small lists. As a useful exercise, maybe people can take a look
at any emr applications they are in contact with, and try to write
a categorical description about the gui , which later might be
writable as a requirement that can be fed to a gui skeleton generating
program.
  Note , if the problem is of inability to flatten a certain display
of a section of the schema out, so that the window generated is too
large to fit the screen, maybe try making a prototype virtual gui that
is actually drawn on a canvas / graphics area, has virtual entry boxes
drop down lists etc,  and is zoomable. 


  Maybe there are a lack of committers because , although important,
ehr functions are basically crud and import/export, and not much fancy
stuff , like word processing, or spreadsheets, or graphics , or
presentations are like; also the audience is a bit limited and mainly
are already locked in with some schema secretive vendor . 







reply via email to

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