openEHRArchetypes/openEHR-EHR-OBSERVATION.ecg.v1: Is <any_allowed>...allowed?

Technical (archive)
1

Hello everyone

I keep getting an error when parsing this ecg archetype (expressed as XML) and i was wondering if this could be because the archetype was uploaded to the CKM when the CKM used a different version of the published openEHR XSDs, if this used to be a bug of the archetype editor or if it could be something that i am doing wrong.

The error i keep getting is "unrecognised element" for <any_allowed>.

In fact, in my small local collection of archetypes*, this archetype is the only one that has an <any_allowed> element as part of its C_COMPLEX_OBJECT definitions.

If i remove <any_allowed>, the archetype is parsed without any problems, but that's usually a way to create problems, not solve them :slight_smile:

I would really like to use this ECG archetype as a test case because it contains a large number of definitions.

According to the specs C_COMPLEX_OBJECT is supposed to inherit "any_allowed" by C_DEFINED_OBJECT but the "Archetype.xsd" does not contain an element / attribute definition for <any_allowed> in any of the relevant class definitions.

This is why i suspect come kind of a (possibly older) mismatch between the CKM / Archetype editor code and the XSDs.

What do you think?

Could this be related to this item as well?
http://www.openehr.org/mailarchives/openehr-technical/msg05970.html

I suppose i can safely remove <any_allowed> (?)

Looking forward to hearing from you
Athanasios Anastasiou

P.S. (*) The 7 Archetypes i am interested in: (encounter, menstrual_cycle_day, blood_pressure, body_temperature, body_weight_adjusted, ecg, height)

2

Hello everyone

I keep getting an error when parsing this ecg archetype (expressed as XML) and i was wondering if this could be because the archetype was uploaded to the CKM when the CKM used a different version of the published openEHR XSDs, if this used to be a bug of the archetype editor or if it could be something that i am doing wrong.

No - the xml in CKM is produced on the fly from the adl, so it is always up to date…
But of course not necessarily always correct: There may well a bug in the generation process of the Java XML generator,
but can someone say definitely if the any_allowed tag should be in the xml or not, first?
(any_allowed is an operation, not an attribute in the constraint model)

Many archetypes have this in CKM, e.g. when a DV_TEXT is not further constrained, this would be expressed in XML using the any_allowed tag.

I assume you refer to this archetype?
http://openehr.org/knowledge/OKM.html#showarchetype_1013.1.276

Sebastian

3

Hello Sebastian

Thank you for your response.

A couple of quick comments:

Yes, the archetype that you are linking is the one i am referring to.

"any_allowed" as an attribute could be inherited from C_DEFINED_OBJECT from http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/aom1.4.pdf (page 27)...It is of course also referred to as a function in C_PRIMITIVE_OBJECT but it has the indication (effected) (?) page 28 on the same document)

All the best
Athanasios Anastasiou

4

ADL example:

DV_TEXT matches {*} – object case

or

value matches {*} – attribute case

In the AOM it is computed to be True if…

  • in a C_ATTRIBUTE there are no children
  • in a C_COMPLEX_OBJECT there are no children
  • in a C_PRIMITIVE_OBJECT, there is no ‘value’, i.e. no attached C_PRIMITIVE (parent type of C_DATE, C_INTEGER etc etc)

I would also expect it to be computed from the XML, since the XML is based in the AOM.

  • thomas
5

Although interestingly the same archetype, saved as XML via the archetype editor (or in .opts) does not include any_allowed elements…

<node_id>at0081</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_TEXT</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 />

Looks like the java parser is behaving a little differently.

Ian

6

Sounds like the Java XML generator needs to be corrected to never spit this out then. This should be straightforward to fix.
I wonder however if this is just in there by mistake and nobody ever cared before that this fairly frequent case breaks the schema or if there was some kind of hidden use case for this.

Sebastian

7

The XML generator had a comment “not sure if needed” next to the any_allowed related code.
So I have removed this now.
A corrected version is deployed to the openEHR ckm.

Regards
Sebastian

8

Well, last time I checked the serialization and the schema this was
one of the things I was not sure which was correct. I have to get some
time to modify the schema with the missing things I detected some time
ago