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.
the rules of ISO 8601 don’t allow silly date/times like that. The rules are described here (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.
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.
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
with respect to the ontology question above, AOM 1.5 defines the ontology classes as follows - including the data structures for the terms & constraints.
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.
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 classes look like the following:
while the AOM 1.5 model simplifies the representation, and also makes it semantically more powerful. This is the representation used in the XSDs:
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.
