I appreciate the list members time and patience.  I used Zope heavily
2000-2003 but after not writing any code for almost five years this is
like starting over. :-)

On Fri, 2008-07-11 at 06:48 +0200, Markus Kemmerling wrote:
> You want to restrict the elements of a list to instances that provide  
> a given interface IMyClass, right? That's exactly what a field's  
> value_type attribute is for: 

Thanks.  I missed that in the docs about collections.

> 
> is meant to be used in class definitions to declare that a class  
> itself -- not is instances -- provides a given interface.
> 

I use that and I guess that's why I thought it might do double duty.

> I am not sure if I get this. If you set an instance of a mutable type  
> like a list as an attribute of some other instance described by a  
> schema, it will be validated, but still remain mutable (finally your  
> other object only holds a reference to your mutable). It doesn't  
> matter if it is persistent or not, or if it was copied before. But I  
> might misunderstand your intention here.

As usual a bit of context will help if you'll bear with me.

I am implementing a set of healthcare application specifications
designed (over almost 2 decades) to maintain semantic context of
information across applications and to be implementable in any OO
language. There are implementations in Eiffel,Java and .Net. 
 http://www.openehr.org This will reduce the number healthcare data
silos since any application in any language can exchange information.

The reference model describes broad concepts such as
observation,instruction,action,etc along with the required data types
and data structures to support them.

The 'instances', referred to above, are created as constraints on the
reference model in order to define a maximal dataset for ONE clinical
concept, i.e. blood pressure. These definitions are parsed from a
special purpose language (see attachment) designed to describe the
entire semantics of that concept.  Since (with my code) parsing one of
these and creating the in-memory object takes  about .1 - .2 secs. and
since an application may use as many as 20 on a screen it is out of the
question to do it on-the-fly.  

My solution then is to pre-store these in a repository in the ZODB as a
kind of template.  An application can then reuse these by making a
copy. 

My priorities are:

1. To demonstrate implement-ability in Python.   

2. Have a platform that can be used to demonstrate and teach the
reference model and archetypes in use to a broad audience; physicians,
health care researchers, computer science and medical students, etc.

3. Build an interested open source community where 'real' developers can
fine tune my code and create wonderful interoperable healthcare
applications using the reference model in their chosen language.


So, yes I am recruiting developers to what I believe is a good cause
project. In the interim I will keep plugging away at.  :-)


Thanks,
Tim





-- 
**************************************************************************
Join the OSHIP project.  It is the standards based, open source
healthcare application platform in Python.
Home page: https://launchpad.net/oship/ 
Wiki: http://www.openehr.org/wiki/display/dev/Python+developer%27s+page 
**************************************************************************

Attachment: openEHR-EHR-OBSERVATION.blood_pressure.v1.adl
Description: application/extension-adl

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

_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Reply via email to