# openEHR schemas
**Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158)
**Created:** 2011-09-30 13:57 UTC
**Views:** 24
**Replies:** 28
**URL:** https://discourse.openehr.org/t/openehr-schemas/13931
---
## Post #1 by @Sauciuc_Dragos
Hello,
After studying the documentation and the xsd schemas published on your website (openEHR Release 1.0.2 Archetype XML schema, Authored by Ocean Informatics 2008.12.22 and OpenEHR Release 1.0.2 documentation) I found out that they are not 100% in sync.
The differences that I found until now are in Archetype package:
1. for complexType C_DATE, C_DATE_TIME, C_TIME, C_DURATION the element name="pattern" is not present in the documentation instead other elements are for i.e month_validity, day_validity, minute_validity, second_validity and millisecond_validity.
2. the other difference is present in the ontology sub package. Here the ARCHETYPE_ONTOLOGY from documentation is quite different form the xsd. In documentation we have terminologies_available, specialisation_depth, term_codes, constraint_codes, term_attribute_names, parent_archetype but in xsd we have term_definitions, constraint_definitions, term_bindings, constraint_bindings.
I am not looking at the correct xsd or documentation? Or are this known issues that need to be solved, keeping in mind that the Archetype Editor seems to be in sync with the xsd schemas but not with the documentation.
Regards,
[details="(attachments)"]
[/details]
---
## Post #2 by @Heath_Frankel3
Dragos,
You need to keep in mind that some of the openEHR models are functional models and don’t lend themselves well to persistence models. These variations were pragmatic decisions made at the persistence level that are not only in the XML but also in the ADL.
We expect to be doing a review of the XML schemas in the near future which are likely to result in further variation to obtain a more efficient XML representation.
Heath
[details="(attachments)"]
[/details]
---
## Post #3 by @yampeku
But if openEHR tries to have 'fully formal and computable
specifications' I feel that they should be exactly the same
---
## Post #4 by @Seref
Hi Diego,
Please search the archives of this mail group, and technical group discussions regarding XML. In fact, we had a discussion only a few days/weeks ago. When XML as a technology or specification can not properly support inheritence and generics how can they be exactly the same?
---
## Post #5 by @yampeku
There are things XML Schema cannot do, but there are others that can
be done and are not being used\. for example, XML schema supports the
definition of ISO8601 date data types, but current official schema
uses a xs:string with a pattern\. just using the correct xs:date,
xs:time, or xs:datetime would be more powerful \(i\.e\. automatic
validation without the need to parse the pattern\) and would make the
schemas less complicated\.
---
## Post #6 by @Seref
I'm sorry Diego,
it appears I've misunderstood your comment. I'm a little bit too busy with the problem I've mentioned. Thomas Beale and I working on producing XSD compliant XSD, these kind of improvements will probably take place in near future, as Heath said.
Regards
Seref
---
## Post #7 by @thomas.beale
I can't remember without checking whether the XSD forms of these types support all the ISO 8601 partial date/time forms, but if they do, this is exactly the kind of change that would be made in the next generation schemas.
Note that making this change is an example of making the schema *diverge* from the published specifications - but in a known, and sensible way. Originally we were trying to be too faithful to the specifications, and the schemas reflect that. It is clear now that the need is not to be rigidly faithful, but to be space-efficient, to employ as much built-in semantic power as possible, while guaranteeing 100% lossless, efficient *transformation* in and out of the in-memory object form. It is this latter form that needs to be 100% the same as the published specifications in its effective semantics (i.e. notwithstanding small divergences due to quirks of various languages that don't affect the final semantics).
BTW - anyone who wants to propose modifications to the current schema, such as this, please do so. You can post candidates for the next generation schema [on the wiki](http://www.openehr.org/wiki/display/spec/XML+Schemas) for people to test & evaluate - partial schemas are fine - please make sure to include sufficient information about what you are posting for people to make sense of it.
- thomas beale
---
## Post #8 by @yampeku
well, specifications say that dv\_dates are strings compliant to
ISO8601, and that's exactly what they would be on the schema\. this
respects more the semantics of the model than currently does
---
## Post #9 by @thomas.beale
yes but the point is that the XSD is now no longer a direct copy of the
specfication model, a small transformation is needed to convert a native
XSD attribute to the equivalent object type\. If they were the same
thing, then the set of classes that you can generate from the XSD would
be identical to those built by hand from the spec\. But they are not\.\.\.
\- thomas
---
## Post #10 by @Sauciuc_Dragos
> I'm sorry Diego,
> it appears I've misunderstood your comment. I'm a little bit too busy with the problem I've mentioned. Thomas Beale and I working on producing XSD compliant XSD, these kind of improvements will probably take place in near future, as Heath said.
>
> Regards
> Seref
Hello,
From what I understood until now the openEHR specifications is "the path to follow" and the xsd isn't 100% in sync with the documentation from various reasons. From my point of view the issues that I raised on this discussion can be solved from technical perspective quite easy by modification of the xsd. This is the "easy part", the "hard part" is represented by all the other tools that are using the adl parser (Ocean Archetype Editor) that seems to respect the xsd and not the specification. From my point of view the openEHR community should stick to a documentation and alterate all the other tools and resources to be 100% in sync with the documentation. If a resource/tool can't follow the documentation than don't used it or change the specification.
Regards,
Dragos
[details="(attachments)"]
[/details]
---
## Post #11 by @thomas.beale
we do need to be clear here: the normative definition of openEHR is the specifications, which define object model semantics. Any given implementation technology expression will have its own divergences due to the limitations of that technology. We have taken a lot of care to accommodate programming technologies with single inheritance and so on, but if we had allowed the inheritance model (in particular) of XML Schema to dictate the specifications, we would be a far weaker position than we are, because the object semantics of XSD, such as they are, do not correspond well to any programming language, and generally represent a hurdle. However, if we take the job of XML Schemas to be: represent a data view that is lossless with respect to the programming view, then it works ok. But to achieve these, the schemas contain all kinds of workarounds, particularly to do with inheritance and generic types.
So, the idea of making XML schema 'exactly like the documentation' means: making its data view lossless, not making it a slavish copy of the models from the documentation (this is simply not doable).
- thomas
---
## Post #12 by @Heath_Frankel3
XSD datetime/date/time does not support ISO8601 partial date time capability
nor the openEHR deviations of the ISO8601 partial date time specification\.
This is why it uses its own restriction of string\.
Heath
---
## Post #13 by @Heath_Frankel3
Domain models and persistent models are rarely the same\. openEHR has
concentrated on Domain models\.
Heath
---
## Post #14 by @Heath_Frankel3
This is not true, as previously mentioned XSD datetime doesn't fully support
ISO8601, the openEHR string restrict is more compliant than XSD datetime\.
It is agreed that the current pattern can be simplified and there is already
a Jira issue to correct an inconsistency\.
Heath
---
## Post #15 by @Heath_Frankel3
Once again, it is the level of Model that is the issue. The openEHR models are domain model specifications and not implementation technology specifications. You could argue that the XSD is the formal openEHR implementation technology specification for the XML ITS for releases 1.0.x, there is accompanying documentation that goes with these schema. There will be a new formal model for the next release.
This is similar to the Eiffel and Java implementations would have variations to the specifications due to language constraints and implementation choices, you too would have implementation variations in your implementation as I do in my c# implementation.
Let’s move on from this purity and just make change suggestions that will really help the next generation of XSD, which as I suggested previously will likely to be more variant from the specifications than aligned.
Heath
Hello,
>From what I understood until now the openEHR specifications is "the path to follow" and the xsd isn't 100% in sync with the documentation from various reasons. From my point of view the issues that I raised on this discussion can be solved from technical perspective quite easy by modification of the xsd. This is the "easy part", the "hard part" is represented by all the other tools that are using the adl parser (Ocean Archetype Editor) that seems to respect the xsd and not the specification. From my point of view the openEHR community should stick to a documentation and alterate all the other tools and resources to be 100% in sync with the documentation. If a resource/tool can't follow the documentation than don't used it or change the specification.
Regards,
Dragos
There are things XML Schema cannot do, but there are others that can
be done and are not being used. for example, XML schema supports the
definition of ISO8601 date data types, but current official schema
uses a xs:string with a pattern. just using the correct xs:date,
xs:time, or xs:datetime would be more powerful (i.e. automatic
validation without the need to parse the pattern) and would make the
schemas less complicated.
2011/10/1 Seref Arikan <[serefarikan@kurumsalteknoloji.com](mailto:serefarikan@kurumsalteknoloji.com)>:
[details="(attachments)"]
[/details]
---
## Post #16 by @yampeku
well, partial dates and times may need specific patterns \(and as you
said, it should be revised as they support impossible dates right
now\)\. However \(and correct me if I am wrong\) there is no such thing as
a partial date\_time \(it makes no sense\)\. So xs:datetime should still
be used\.
---
## Post #17 by @Heath_Frankel3
Sorry, in healthcare partial date times are used all the time\.
---
## Post #18 by @yampeku
like 1 year and 20 seconds?
---
## Post #19 by @mikael
At least like "It happened three months ago in the afternoon"\.
/Mikael
---
## Post #20 by @Sauciuc_Dragos
> we do need to be clear here: the normative definition of openEHR is the specifications, which define object model semantics. Any given implementation technology expression will have its own divergences due to the limitations of that technology. We have taken a lot of care to accommodate programming technologies with single inheritance and so on, but if we had allowed the inheritance model (in particular) of XML Schema to dictate the specifications, we would be a far weaker position than we are, because the object semantics of XSD, such as they are, do not correspond well to any programming language, and generally represent a hurdle. However, if we take the job of XML Schemas to be: represent a data view that is lossless with respect to the programming view, then it works ok. But to achieve these, the schemas contain all kinds of workarounds, particularly to do with inheritance and generic types.
>
> So, the idea of making XML schema 'exactly like the documentation' means: making its data view lossless, not making it a slavish copy of the models from the documentation (this is simply not doable).
Hi Thomas,
I think that the community should use the xsd's to validate the xml's and not to use them for generating class models. If this means to make "workarounds" inside the xsd to validate a xml I agree with that. With the risk to repeating myself this is the "easy part", the "hard part" is that all the archetypes that are published (I am referring to the archetypes from CKM) they don't respect the specification because the ADL generated by the Ocean Archetype Editor doesn't follow the documentation. I did mentioned in a previous email some examples where the documentation is not followed.
Regards,
Dragos
[details="(attachments)"]
[/details]
---
## Post #21 by @Sauciuc_Dragos
> Once again, it is the level of Model that is the issue. The openEHR models are domain model specifications and not implementation technology specifications. You could argue that the XSD is the formal openEHR implementation technology specification for the XML ITS for releases 1.0.x, there is accompanying documentation that goes with these schema. There will be a new formal model for the next release.
>
> This is similar to the Eiffel and Java implementations would have variations to the specifications due to language constraints and implementation choices, you too would have implementation variations in your implementation as I do in my c# implementation.
>
> Let’s move on from this purity and just make change suggestions that will really help the next generation of XSD, which as I suggested previously will likely to be more variant from the specifications than aligned.
>
> Heath
Hi,
I am more than happy to make some xsd's and publish them to wiki to help the community to align the xsd's with the specifcation.
Regards,
Dragos
[details="(attachments)"]
[/details]
---
## Post #22 by @thomas.beale
the rules of ISO 8601 don't allow silly date/times like that. The rules are described [here](http://www.openehr.org/releases/1.0.2/architecture/rm/support_im.pdf) (p27). One reason partial date/times occur frequently is due to having a date/time field specified in a message or form, but the actual data from a patient is only the year, your + month, or maybe year + month + day + hour in day. The data type doesn't change - its still a date/time (DV_DATE_TIME) so unless partial forms are allowed, no data at all are recorded.
- thomas
---
## Post #23 by @Seref
Hi Dragos,
XSD based code generation is one of the most established practices of software development for the last decade. I won't go into justifying this practice, but I'll certainly claim that generation of source code from a standard based formalism is a good thing and it should be supported.
I disagree with your classification of easy and hard: on one hand you have the problem of creating an ITS to address various platforms, on the other you're talking about an update to a finite, and not so large set of technical artifacts.
Regards
Seref
2011/10/4 Sauciuc Dragos <[dragos_sauciuc@intelmed.ro](mailto:dragos_sauciuc@intelmed.ro)>
---
## Post #24 by @yampeku
year and year\+ month are partial dates and could be represented with dv\_date
in the last case, I don't really see a lot difference between storing
y\+m\+d\+h from storing a datetime with also the minutes and seconds
---
## Post #25 by @Heath_Frankel3
That is a Duration\. Like 1980 or 20111004T10\.
---
## Post #26 by @thomas.beale
I just realised I had not responded to the above points....
with respect to the C_DATE_TIME etc constraints, the [AOM 1.4 model](http://www.openehr.org/releases/1.0.2/architecture/am/aom.pdf) classes look like the following:
while the [AOM 1.5 model](http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/aom1.5.pdf) simplifies the representation, and also makes it semantically more powerful. This is the representation used in the XSDs:
---
## Post #27 by @thomas.beale
with respect to the ontology question above, AOM 1.5 defines the ontology classes as follows - including the data structures for the terms & constraints.
---
## Post #28 by @Sauciuc_Dragos
>
> > Hello,
> >
> > After studying the documentation and the xsd schemas published on your website (openEHR Release 1.0.2 Archetype XML schema, Authored by Ocean Informatics 2008.12.22 and OpenEHR Release 1.0.2 documentation) I found out that they are not 100% in sync.
> > The differences that I found until now are in Archetype package:
> >
> > 1. for complexType C_DATE, C_DATE_TIME, C_TIME, C_DURATION the element name="pattern" is not present in the documentation instead other elements are for i.e month_validity, day_validity, minute_validity, second_validity and millisecond_validity.
> > 2. the other difference is present in the ontology sub package. Here the ARCHETYPE_ONTOLOGY from documentation is quite different form the xsd. In documentation we have terminologies_available, specialisation_depth, term_codes, constraint_codes, term_attribute_names, parent_archetype but in xsd we have term_definitions, constraint_definitions, term_bindings, constraint_bindings.
> >
> > I am not looking at the correct xsd or documentation? Or are this known issues that need to be solved, keeping in mind that the Archetype Editor seems to be in sync with the xsd schemas but not with the documentation.
>
> I just realised I had not responded to the above points....
>
> with respect to the C_DATE_TIME etc constraints, the [AOM 1.4 model](http://www.openehr.org/releases/1.0.2/architecture/am/aom.pdf) classes look like the following:
>
> 
>
> while the [AOM 1.5 model](http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/aom1.5.pdf) simplifies the representation, and also makes it semantically more powerful. This is the representation used in the XSDs:
>
> 
I looked for stable documentation so I studied the documentation from [**MailScanner has detected a possible fraud attempt from "www.openehr.org" claiming to be** openehr.org->specifications->release1.0.2](http://www.openehr.org/releases/1.0.2/roadmap.html); I was expecting that [openEHR Release 1.0.2 Archetype XML](http://www.openehr.org/svn/specification/TAGS/Release-1.0.2/ITS/XML-schema/Archetype.xsd) schema should respect that specification. Now i see that the xsd is actually 1 step in front and follows the development version of the next release. This kind of issues can be confusing from my point of view and can lead to unnecessary discussions also in the future.
---
## Post #29 by @Heath_Frankel3
Dragos,
No specification is perfect, and each model has a particular view-point. In the case of the ONTOLOGY model it was more of a service/functional model rather than a data model as it is in most of the other packages. The next release of ADL 1.5 learnt from the shortcomings of the ADL 1.4 specification and aligned itself with the ADL and XML schema (the variations you indicated are also in the ADL persistence, not just the XML schema). So as I previously indicated, one option you didn’t consider is changing the specification to align with the ITS, which is exactly what has happened in this particular case.
Regards
Heath
[details="(attachments)"]
[/details]
---
**Canonical:** https://discourse.openehr.org/t/openehr-schemas/13931
**Original content:** https://discourse.openehr.org/t/openehr-schemas/13931