oship-dev team mailing list archive

[Roger Erens <roger.erens@xxxxxxxxx>]

Starting up a new thread...

>   Now, concerning the "adl2py" experimental branch: instead of
> > "grokifing" the .ADL files, maybe it'll be enough to convert them into
> > an intermediary format that Zope/Grok already knows how to handle (e.g.
> > XML or, better yet, JSON: http://www.json.org and:
> > http://en.wikipedia.org/wiki/JSON). What do you think?

There are some issues with this and one very fundamental issue that I
think many people do not see.

Remember that the ADL represents and archetype that is a constraint
expression on the reference model.

What this means in practical terms is that if you only 'convert' what is
in the ADL to some other format, you still haven't created a class that
can be instantiated as openEHR data.

For example let us look at simple ADL file like
openEHR-EHR-COMPOSITION.encounter.v1.adl  it shows that you need the
class COMPOSITION with an archetype node id of at0000 and it has one
attribute named category and category contains an instance of
DV_CODED_TEXT with the defining_code being openehr::433.  That's it,
that's all you get from the ADL.

In reality the COMPOSITION class has three other mandatory and two other
optional attributes.  It also inherits from LOCATABLE which adds an
additional 6 attributes.

There are developers out there right now that say they are using openEHR
archetypes because what they are doing is mapping what they find in ADL
to their data model.  They will eventually discover (because they
haven't read and listened yet) that the 'data' they produce is not
openEHR compatible because it lacks so many components.

So my move to 'grokifing' OSHIP is to use the grok classes as mixins in
places where needed so that it will be easier for people that do not
understand or want to know how the openEHR model works, to still be able
to build applications that create fully compatible openEHR data.

In the end we will have a lot of extra code.  Things like the AQL
translation engine will have to know how to translate a query into the
query expected by the catalog/indexing components of the ZCA.  The EHR
Extract module will have to do the same.

It is a lot of extra work but the upside is more openEHR applications
being built on a platform that people are more comfortable with and
knowledgeable about.

So, the short answer is that we need to take the ADL, build a Python
source code file containing the class.  In the example
openEHR-EHR-COMPOSITION.encounter.v1.adl the class name is EncounterV1.
It lives in km/openehr/ehr/entry/observation directory and expresses all
of the RM classes with the ADL constraints applied.  This class can then
be used in any appropriate place in an application.  The Python files
can then be reused/shared among the OSHIP community.

Does this explain my approach to 'grokifing' a little better?

Comments are not only welcome but encouraged.

Cheers,
Tim