oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

Hi All,

I would really like to get some thoughtful feedback on this.

On Tue, 2010-06-22 at 01:14 -0500, Tim Cook wrote:
> On Tue, 2010-06-22 at 00:58 -0500, Tim Cook wrote:
> > At this point you know it validated through the SAXparser.
> 
> This is true.  But, it doesn't mean it is a valid archetype.  You'll
> need to read the section in the PyXB docs about BIND and using anonymous
> elements.
> http://pyxb.sourceforge.net/userref_usebind.html 

I wanted to follow this up and point out some significant thoughts.  

What Tarsis is doing in HKCR at this point is using the XML
representation of archetypes (I assume from the CKM
http://www.openehr.org/knowledge/ ) and attempting to validate them
against the RM XML Schemas.

However, I can given this issue some thought and discussed it with
experts in the multi-level modeling approach.  The concept that openEHR
uses of creating blank XML documents that represent archetypes doesn't
really fit the concepts of multi-level modeling. 

Multi-level modeling (openEHR or MLHIM) has a basic concept of layered
constraint expressions against a common reference model built in
software.  So, in openEHR there are archetypes and templates.  In MLHIM
we redefine archetypes as Concept Constraint Definitions (CCDs) and
templates as Template Constraint Definitions (TCDs).  This renaming is
not;"just to be different". It based on several years of experience by
myself and others when explaining the concepts to others outside of the
openEHR community.  

But, back to the point. Since each level (CCDs, TCDs, etc.) are supposed
to represent narrowing constraints against a reference model then it
makes more sense (in my mind at least) that these are represented as XML
Schemas, not XML documents. XML documents are meant to contain data
instances, not be a model.  

So along these lines of thought.  The existing XML Schemas at
http://www.mlhim.org/schemas/openehr/v1/

represent the reference model. CCDs and TCDs should be schemas that
represent whatever further constraints are desired.   So instead of
openEHR-EHR-OBSERVATION.apgar.v1.xml you would have
openEHR-EHR-OBSERVATION.apgar.v1.xsd that is a model for Apgar instances
which are expressed as XML documents that can be used in any application
written in any language. 

Again, I would really appreciate any feedback on this as well as
corrections to my thought processes.

Regards,
Tim




-- 
***************************************************************
Timothy Cook, MSc

LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
Skype ID == (upon request)
Academic.Edu Profile: http://uff.academia.edu/TimothyCook

You may get my Public GPG key from  popular keyservers or    
from this link http://timothywayne.cook.googlepages.com/home

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