[Zope-dev] [Zope3-Users] Next Step to Bug Resolution???

[Tim Cook]

Hi Dan,

Thanks for taking a look.

On Thu, 2008-12-18 at 20:06 +0300, Dan Korostelev wrote:
> Hi, Tim.
> 
> I builded out your application and took a quick look at the error. It
> looks like you're mis-using the zope.schema.Field class and its
> interface. It should be only used in schema definition, while you are
> using Field instances as attributes for other objects. For example,
> you are defining the ObjectId as a field, but are using its instances
> as objects. That's not a valid use.

Okay.  I can accept that it might be a mis-use. 

> 
> I extracted the problematic code to separate file and changed the
> IField to Interface and Field to ``object`` (though you'll want to use
> Persistent, i guess) for ObjectId and ObjectRef and it works okay. :-)
> 

This is actually what I did at first.  You may want to refer to the UML 
http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/architecture/computable/UML/uml_start_view.html 

(This is the rm.support.identification package we are looking at)

Since ObjectId is an abstract class so inheriting from object seems
reasonable.  However, most of the other id classes inherit from ObjectId
and when they are used as attributes to other classes they need to have
the meta data expected by zope.schema.  Otherwise you get errors like
"keyword required not found" (or something similar).  This is true
throughout the model.   So my solution (and CERTAINLY there may be a
better one) was to use the Field class (it is just a Python class -
right?) as the base class for all of the base classes in the model.

As I said before I may have miss-diagnosed the problem and may fix may
break other things?   


> Or, it might be that I don't fully understand your code and
> application architecture, so I would like to hear more about it. It
> looks quite over-engeneered to me.

I fully understand why you might think that.

IF you'll bear with me... healthcare information is very complex
(certainly the complex domain I've run into in 32 years of dealing with
information systems) and the knowledge domain is constantly changing.  I
have a short point paper here
http://timothywayne.cook.googlepages.com/context-lies.pdf that gives a
30,000' view of the issues of semantic interoperability and
computability of healthcare information.

and a good introduction to the domain issues are here:
http://www.openehr.org/shared-resources/getting_started/openehr_primer.html 


This model has more than 20 years of constantly improving R&D on this
subject.  The key goal have always been to be abstract enough so that it
can be implemented in any OO language on any platform in any type of
healthcare setting and all stored patient information is guaranteed to
be computable (decision support, etc) as well as maintain it's semantic
integrity over the course of time irregardless of the changes in the
science.  So in essence you can go back to any point in time and not
only know what the blood pressure of the patient was, but also "what was
known" about blood pressure at that time. 

This model has been implemented in Eiffel, Java, C# and VB.  The
applications (both commercial and open source) have demonstrated these
capabilities.  

Certainly the model isn't perfect but there is a completely open change
management system in place that deals with any changes due to new ares
or new science.  

In order for this Python implementation to remain as true as possible to
the model as well as exercise the value in the ZCA; this is the path I
have taken.  

Thanks for your help.

Cheers,
Tim



   


-- 
Timothy Cook, MSc
Health Informatics Research & Development Services
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
Skype ID == timothy.cook 
**************************************************************
*You may get my Public GPG key from  popular keyservers or   *
*from this link http://timothywayne.cook.googlepages.com/home*
**************************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oe_trick.png
Type: image/png
Size: 7092 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20081218/a2bb55cf/attachment.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20081218/a2bb55cf/attachment.bin