rm_type_name for the DV_DURATIONs primitive object in XML

Technical (archive)
1

Dear all,

There are a differences in how the Template Designer and how CKM construct the XML for a DV_Duration:

Take this snippet (from http://openehr.org/ckm/#showArchetype_1013.1.123_XML )

<rm_type_name>DV_DURATION</rm_type_name>

<lower_included>true</lower_included>

<upper_included>true</upper_included>

<lower_unbounded>false</lower_unbounded>

<upper_unbounded>false</upper_unbounded>

1

1

<node_id />

<rm_attribute_name>value</rm_attribute_name>

<lower_included>true</lower_included>

<upper_included>true</upper_included>

<lower_unbounded>false</lower_unbounded>

<upper_unbounded>false</upper_unbounded>

1

1

<rm_type_name>DV_DURATION</rm_type_name>

<lower_included>true</lower_included>

<upper_included>true</upper_included>

<lower_unbounded>false</lower_unbounded>

<upper_unbounded>false</upper_unbounded>

1

1

<node_id />

PMWD

<lower_unbounded>true</lower_unbounded>

<upper_unbounded>true</upper_unbounded>

What is the correct rm_type_name for C_PRIMITIVE_OBJECT here (in old red above)?

Is it “DV_DURATION” as the Java Ref Impl uses or is it simply “DURATION” (both for reason I don’t really understand)

or should it maybe be “String” or “ISO8901_DURATION” as

http://openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1433773264460_352968_7042 and/or

http://openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1422968609347_115062_25681 describe.

Frankly I am confused, but I hope that someone can enlighten me here?

Cheers

Sebastian

2

Hi,

according to the specs it's String: http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_duration_class
That's what template designer does.

Best regards,
Bostjan

3

Agree with bostjan, In fact DV_DURATION type is being assigned to both
the C_Complex_object and the C_Primitive_object rm_type_name, which is
surely wrong.

4

OK, that would have been my pick as well.

Only that:
- The Java Ref Impl exports it as DV_DURATION (It seems we all agree that this is wrong)
- Template Designer (2.8) exports this as "DURATION" (in the generated OPT).
- The online Template Editor seems to export it either as C_DURATION or DURATION in the 1.4 OPT export (depending on what is constrained?!)

So it seems that C_DURATION is another candidate.

I could however not get any of the tools to just use "String"...

Sebastian

5

To make things worse, in the XML Schema DV_DURATION contains an
Iso8601Duration, which in the end is an string with a regex

6

Sebastian/Diego,

You’re absolutely right - sorry I have been too quick in my reply.

I think what template designer 2.8 (2.6 does the same BTW) does is correct this is the same as we always had.

However there is still a bug in CKM opt generation - but for INTERVAL<DV_DURATION> what it does there is at the wrong level.

I don’t have the new AE which supports INTERVAL<DV_DURATION> so I tried this with INTERVAL<DV_DATE_TIME> and I get this:

DV_INTERVAL<DV_DATE_TIME> true true false false 1 1 upper true true false false 0 1 **DV_DATE_TIME**

so INTERVAL.upper is of type DV_DATE_TIME, which is the correct type.

However for INTERVAL<DV_DURATION> I get the following:

DV_INTERVAL<DV_DURATION> true true false false 1 1 upper true true false false 1 1 **DURATION**

So here the INTERVAL.upper type is DURATION, which is clearly wrong - it should really be DV_DURATION.

Best regards,
Bostjan

7

Hi Sebastian,
Does this mean that CKM no longer uses the TD OPT Web Service?

I think your suggestion of String is correct as per the specifications, DURATION, DV_DURATION and C_DURATION are clearly wrong.

However, I think we need to be considering the XML Schema approach of a restricted string since the RM does have an invariant of is_valid_iso8601duration. I think this needs to be more specifically implied using the assumed ISO8601_DURATION class which would allow this to be used in the OPT but I think this needs to be considered by the SEC before we adopt this approach.

For now I suggest all tools are updated to use String to align with the spec.

Regards

Heath

8

Hi Sebastian,
Does this mean that CKM no longer uses the TD OPT Web Service?

[SG] CKM is still using the webservice:
The OPT displayed in CKM is retrieved from the TD OPT webservice by sending the archetypes in XML.
The XML is generated by the Java XML serialiser, however I postprocess this and replace DV_DURATION with DURATION in this case.
The original reason for this was consistency of MD5 Canonical Hash calculation.
(However, I am now able to send the ADL directly to the webservice to calculate the hash, which gets around this problem and ensures consistency of the hash with TD.
There is (or was) a similar issue for (DV_) date and time elements and some other minor issues which made this the more reliable approach.)

But this is why at the moment the Archetype XML in CKM would use DV_DURATION while the OPT in CKM would use DURATION - which is clearly insufficient.

Need to think more about the rest below...cheers for now, Sebastian

I think your suggestion of String is correct as per the specifications, DURATION, DV_DURATION and C_DURATION are clearly wrong.

However, I think we need to be considering the XML Schema approach of a restricted string since the RM does have an invariant of is_valid_iso8601duration. I think this needs to be more specifically implied using the assumed ISO8601_DURATION class which would allow this to be used in the OPT but I think this needs to be considered by the SEC before we adopt this approach.

For now I suggest all tools are updated to use String to align with the spec.
Regards

Heath

9

Dear all,

There are a differences in how the Template Designer and how CKM construct the XML for a DV_Duration:

Take this snippet (from http://openehr.org/ckm/#showArchetype_1013.1.123_XML )

<rm_type_name>DV_DURATION</rm_type_name>

<lower_included>true</lower_included>

<upper_included>true</upper_included>

<lower_unbounded>false</lower_unbounded>

<upper_unbounded>false</upper_unbounded>

1

1

<node_id />

<rm_attribute_name>value</rm_attribute_name>

<lower_included>true</lower_included>

<upper_included>true</upper_included>

<lower_unbounded>false</lower_unbounded>

<upper_unbounded>false</upper_unbounded>

1

1

<rm_type_name>DV_DURATION</rm_type_name>

<lower_included>true</lower_included>

<upper_included>true</upper_included>

<lower_unbounded>false</lower_unbounded>

<upper_unbounded>false</upper_unbounded>

1

1

<node_id />

PMWD

<lower_unbounded>true</lower_unbounded>

<upper_unbounded>true</upper_unbounded>

What is the correct rm_type_name for C_PRIMITIVE_OBJECT here (in old red above)?

Is it “DV_DURATION” as the Java Ref Impl uses or is it simply “DURATION” (both for reason I don’t really understand)

or should it maybe be “String” or “ISO8901_DURATION” as

http://openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1433773264460_352968_7042 and/or

http://openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1422968609347_115062_25681 describe.

Frankly I am confused, but I hope that someone can enlighten me here?

Cheers

Sebastian

10

What is EN13606 specifying?
What about in the new release?

In my opinion.
Duration is a derived attribute of an episode of a process.
It is expressed in absolute terms in units of measurement that express any number of time units.
Or in relative terms in relation to an other episode (process) or point in time. Plus a relationship between the two.

Point in time can be absolute: expressed as a point on the time line with a defined granularity
Or relative to an other point in time or an episode (process) plus the relationship between the two.

In archetype models we need an archetype pattern to specify all these possible patterns.
What I describe is not really a Data Type, but a complex archetype pattern.

I only need the point in time data type
and a standard way to define attributes of any episode(process).

Gerard Freriks
+31 620347088
gfrer@luna.nl

11

Yes, that seems be another possible interpretation of the specs.

So, it could be ISO8601_DURATION with a possible C_DURATION constraint underneath.

Or it could be a STRING with a possible C_STRING constraint underneath.

Semantically, it seems to be pretty much the same (because of the invariant), but syntactically it matters for anybody or a tooling having to deal with this.

I prefer it to be the first, I think, because it is clearer, and from what I understand this is your and Heath’s preference of what it should(!) be as well.

But for now, looking at the specs, it clearly says String [with an invariant]…so it seems that that is what it needs to be changed to?

This includes changing the C_DURATION underneath to a C_STRING as well, I would assume across the various tools.

I just wonder why it was modelled that way in the specs (was it just an oversight, or is there a good reason such as that Duration is not (usually) an inbuilt datatype)

Cheers

Sebastian

12

I think a C_DURATION can add constraints over the width of the duration (between two given values, below given value, above given value, i.e. an interval, this is really for the magnitude = duration to seconds or milliseconds, so it will be interval, or to the string expression itself with regex for example.

The problem with the regex is that should be an ISO8601_DURATION valid regex, but more constrained, like years between 2 given years or greater than give year, etc. Not sure if we need this kind of (over) engineering / complexity on the archetypes. I would go just with constraining the magnitude width, and let the more specific constraints to be implemented at the software level.

IMO, we need ISO8601_DURATION to represent the internal structure, and C_DURATION for data constraints, to be part of DV_DURATION constraints.