In my opinion the best design is to have one schema per information model. This facilitate a logical division of the designed types and to keept in mind the reference model. The use of namespaces is a good idea to clarify thinks (I belive). To use this philosophy for representing RM in OWL gives an easy way to understand ontologies so for XML-schema I think it will be good too. Regards Isabel Rom?n ----- Original Message ----- From: "Thomas Beale" <[email protected]> To: "Openehr-Technical" <openehr-technical at openehr.org> Cc: "'Heard_Sam'" <sam.heard at OceanInformatics.biz> Sent: Thursday, October 20, 2005 3:22 PM Subject: openEHR XML-schema Questions
> Dear all, > > Sam Heard at Ocean Informatics has built a schema for openEHR, to be published open source on openEHR.org as soon as possible. There remain some open questions about how best to componentise XML-schemas.. The current structure is as three schemas which correspond to 3 pragmatic groupings of classes in the openEHR reference model. The 3 schemas are available (in HTML viewable form) at: > > a.. http://oceaninformatics.biz/schema/documentation/Composition.xsd.html > b.. http://oceaninformatics.biz/schema/documentation/Content.xsd.html > c.. http://oceaninformatics.biz/schema/documentation/BaseTypes.xsd.html > The two higher ones use the next ones down, in a simple chained-inclusion fashion; each schema is locally given its own prefix when used in other schemas, e.g. types defined in the 3rd schema are denoted bt:XXXX where they are used in the other schemas ("bt" = base types).. > > The problems we might have are: > > 1.. a top-level type called LOCATABLE is defined in both the Composition and Content schemas above but in the openEHR reference model it is really a base type which is inherited into nearly everything. Would it be better if we put such classes into a separete small schema, and inherited them (without namespacing)? > 2.. a bunch of classes representing the openEHR clinical data structures are in the Content schema, along with openEHR ENTRY, OBSERVATION, SECTION and other classes. The data structure classes will be required by the openEHR demographic schema, when we write it, but not the ENTRY etc classes. Should we split it out into another includable schema? > When the DSTC did an original openEHR XML-schema about 2 years ago, they had one schema per infomration model (i.e. per major top level package) in openEHR, and did not use namespacing with inclusion (i.e. no prefixes on references to included types). They also had a "core" schema which included everything into it, giving the effect of one big schema. Is this approach or the other better? It should be noted that the schemas posted are already in use and work reasonably well, so this is not a question making them work at all, it is a question of good design. > > - thomas beale > > -- > ____________________________________________________________________________ _______ > CTO Ocean Informatics (http://www.OceanInformatics.biz) > Research Fellow, University College London (http://www.chime.ucl.ac.uk) > Chair Architectural Review Board, openEHR (http://www.openEHR.org) > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
