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:
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.
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.
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.
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?
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.
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.
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 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.
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
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...
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.
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).
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.
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.
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.
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.
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.
