mlhim-owners team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

On Wed, 2011-02-23 at 14:13 +0100, Roger Erens wrote:
> And EMF being Java-oriented:
> EMF -> [XSD] + OSHIPpy
> ?
> And, there are no schemas going 'into EMF'? In the MLHIM-specs of the
> reference model you write down the XSDs that come out of EMF?
> 

You can likely find contradictory information in places and I will need
help cleaning it all up  at some point.  That is simply because this
whole  project is an evolution.  As I learn more and also as more people
join up  with with various bits of expertise.  It is only sensible to
add their input.

What I haven't done well is to communicate these ideas and changes back
to everyone else.  

It really helps tremendously when people do as you have done and write
your thoughts and questions on the mailing list. Then things do not need
to be repeated.  :-) 

To this point:
There were schemas that went into EMF initially.  They worked and
produced a model.  However, when creating diagrams they came out a
little dodgy.  :-)  

After using EMF a bit I thought that it is good to use a formal
modelling process andwe would naturally think of UML.  However, it seems
that implementation of tools for UML2 is not consistent and there is
general unrest in that area.  

EMF is very popular.  It is fairly easy to use, as far as modelling
tools are concerned. My thoughts are that if we use EMF to produce XSDs
as the reference implementation.  Then we have a good modelling tool
that we are not strictly tied to because in reality the schemas are the
reference model.  Every OO language has tools that can bind XML schemas
to their object models.  In Python we would use PyXB.  This way we can
create a generic reference model that is consistent across languages and
easy for developers to create a platform around.  

> >
> > for the clinical concept constraints:
> > [ideas of clinicians] -> [MindMaps] -> [CCD]
> 
> The tools in between are Mindmap and Plone?

XMind as a draft, graphical tool for domain experts.  Then HKCR as a
Plone plugin handles the workflow of drafts and up through publication.
There is a general workflow on this on the MLHIM website under Tools. I
should have something more detailed next week.  


> Just wanted to make that sure; I was playing a little bit devil's
> advocate here :-)

...

> Glad you take it like that instead of criticism,

Quite the opposite.  I would much rather have people tossing their ideas
into the mix than me sitting here sending out emails as if they are some
decree.  

My hope is that this whole project becomes a huge concentration of many
good ideas from lots of people with lots of expertise.  

For example.  I still thought that it would be best to use parts of the
Zope Component Architecture in the Python RM.  However, after thinking
about what Ian has said regarding various frameworks (Django, etc.) It
makes more sense to use PyXB to create Python bindings and then Django,
Plone, Grok, Bluebream, web2py, Pylons, TurboGears, etc.
(http://wiki.python.org/moin/WebFrameworks ) developers can create
wrappers for their own templating and persistence layers.  

If Ian had not expressed this desire then I probably would have stuck
with the ZCA ties. 


Restated another way.  Nothing I say is set in stone.  I do have some
experience in this area and if I disagree with your idea.  I will always
attempt to do so with a good reason. 

Cheers,
Tim

Attachment: signature.asc
Description: This is a digitally signed message part