Hi Dan,

On Sat, 2009-01-17 at 01:28 +0300, Dan Korostelev wrote:
> Hi Tim.
> Unfortunately I didn't follow the discussion lately, so may be the
> problem is no more, but...

There has been a tremendous amount of help from folks like you.  However
there is still not a solution.

I have been asked several times for a 15 minute overview.  This is tough
given the complexity but allow me to ask the question at a more basic
level.   I believe it is similar to the way I asked it last year, but
here goes.

I'm not going to address Field or Object here, just explain the basics.

class DataStructure(Persistence):
   """abstract class"""

class ItemStructure(DataStructure):
    """abstract class"""

class ItemList(ItemStructure):
    Logical list data structure, where each item has a value and can be
referred to by a name 
    and a positional index in the list. The list may be empty.

    items = List(
        description=_(u"""Physical representation of the list."""),

class ItemTable(ItemStructure):
        Logical relational database style table data structure, in which
columns are
        named and ordered with respect to each other.
        Implemented using Cluster-per-row encoding. Each row Cluster
must have an
        identical number of Elements, each of which in turn must have
identical names
        and value types in the corresponding postions in each row.
        Some columns may be designated 'key' columns, containing key
data for each
        row, in the manner of relational tables. This allows row-naming,
where each row
        represents a body site, a blood antigen etc. All values in a
column have the same
        data type.
        Used to represent any data which is logically a table of values,
such as blood
        pressure, most protocols, many blood tests etc.
        Not used for time-based data, which should be represented with
the temporal
        class HISTORY.. The table may be empty.

class ItemSingle(ItemStructure):
    Logical single value data structure.
    Used to represent any data which is logically a single value, such
as a person's height or weight.   

There are others and I left out the attributes and methods of these
classes; with the exception of ItemList attribute 'items', where it is a
zope.schema List but the value types are restricted to the schema
described by IElement (also part of openEHR); but I think you get the

These classes are used as the base software for all openEHR
applications.  Of course the classes get more complex and  deal directly
with healthcare related issues.

Now there are thousands of applications that will have data instance
with attributes expressed in classes based on the above software that
represent single (but complete) clinical concepts.  But not all
application user interfaces will use all available attributes of the
concept.  One may  use an ItemTable and another an ItemList but they
will both be valid in ANY application because the attribute represents a
legal instance of ItemStructure.  

When that data instance is sent from application to another the
receiving applications still needs to know the complete semantic context
of when that data was collected.    Think medico-legal, research and
decision support over the lifetimes of patients and populations.  So
even if the user didn't see all the options in their GUI; it is still
all contained in the data that was transfered. 

So how do I build my schemas so that Zope does the validation of nested
schemas and even lets me use standard widgets?

I hope this was less than 15 min.  For those that want specific examples
I can list a few.


<<attachment: oe_trick.png>>

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

Zope3-users mailing list

Reply via email to