Hi All, This is different than the issues brought up by Rong in the Java implementation.
I brought this up before when reading the specs. But now as my code has matured my fears are confirmed. Using Python: In an interface I define attributes of a class. In addition to some meta-data I define the 'type' of that attribute. Code is here; http://www.openehr.org/wsvn/ref_impl_python/TRUNK/oship/src/oship/openehr/am/archetype/?rev=0&sc=0 For example in IArchetype (the Archetype interface) I define ontology as an ArchetypeOntology type. Now Archetype of course is supposed to implement IArchetype. IArchetypeOntology defines parentArchetype as an Archetype type. This creates a circular dependency when the interfaces try to create a datatype based on a class that depends on itself. The same thing happens with DvMultimedia.thumbnail being of the DvMultimedia type. Other languages may handle these issues differently but I'll be surprised if the same issue isn't raised in the Ruby implementation??? I have tried various delayed import approaches but they do not solve this problem. My solution for Archetype.parentArchetype is to make it an ArchetypeId type. My solution for DvMultimedia.thumbnail is to create a Thumnbnail class that mirrors DvMultimedia without the thumnbnail attribute. All thoughts, comments, suggestions are welcome. 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: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080703/152d8a44/attachment.asc>
