oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

On Fri, 2010-08-06 at 13:42 -0300, Diego Manhães Pinheiro wrote:
>         
> These modules was generated by the adl2py code generator, correct ?

Yes.

> So, why they are necessary to the OSHIP, if they can be generated any
> time you want ? 

Right.  I deleted them for now in my code. 

>  They aren't used by any other module and they don't have tests. 

I see some OSHIP concepts are missing here.  See below.

> I didn't catch how important is these files to the oship system. Could
> you explain me ? I didn't catch their purpose .

I'll attempt an overall explanation below. 

>         
> This approach changes how I understand what is the OSHIP project. 

That is obviously the case. 

> At the moment, OSHIP project is only and just only the implementation
> of the openEHR model. 

This is incorrect.  You are *only* working on that portion right now. 

> Until that I know, the purpose of all openEHR components is mix all
> concepts from different models (hl7, ISO 18308, CEN) into a model that
> communicate with all definitons described by each different
> specification. My point is if separate them means that OSHIP approach
> is leaved aside.
> Could you explain me this too ?

Okay. OSHIP == Open Source Healthcare Information PLATFORM

In this context a PLATFORM == a solid base upon which interoperable
applications can be constructed.

Also see: http://dictionary.reference.com/browse/platform 

So OSHIP is and always has been defined as an application development
platform.  The ultimate goal is to have an infrastructure where
information from multiple places based on multiple models can be brought
together or disseminated from. 

Even if it were only going to be openEHR though, you will note in the
openEHR documentation that the top-level namespace is 'openehr'.  This
is easily seen in the ADL documentation where the naming of archetypes
is discussed. 

We cannot know exactly what applications will be built on OSHIP.  This
is a key concept to the overall project. 

Now to revisit those other modules.

The km (knowledge models) branch is used to contain the python
representations of the constraint models.  The reason we want to do this
is for application speed at runtime.  If the ADL (openEHR) or XSD
(MLHIM) models have to be parsed each time at runtime this is very
inefficient. If they are converted one time to python the each time an
instance needs to be created it is much faster.  ADL and XSD files are
used to transport the same knowledge models to different applications on
different platforms in different programming languages. 

Think about having a data entry screen with maybe 50 - 100 constraint
definitions.  Then they may (likely will) have dependencies on each
other at runtime as well.    


> I take your point, but there are some points that need be clear before
> this merge be done. 

I hope I have answered your questions.  But eitherway; the openEHR
top-level namespace is 'openehr' not 'rm'.  You have openehr.rm and
openehr.am 

Cheers,
Tim

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