Different types for TRANSLATION_DETAILS.language in XSD and BMM for OPT 1.4

XML Schemas for OPT 1.4 specify TRANSLATION_DETAILS in the Resource.xsd.

TRANSLATION_DETAILS.language is specified as type CODE_PHRASE in XSD but it has type TERMINOLOGY_CODE in openehr_base_110.bmm.

May I ask for guidance on which one is correct or if I’m missing something?

<xs:complexType name="TRANSLATION_DETAILS">
<xs:sequence>
  <xs:element name="language" type="CODE_PHRASE"/>
  <xs:element name="author" type="StringDictionaryItem" minOccurs="1" maxOccurs="unbounded"/>
  <xs:element name="accreditation" type="xs:string" minOccurs="0"/>
  <xs:element name="other_details" type="StringDictionaryItem" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
["TRANSLATION_DETAILS"] = <
	name = <"TRANSLATION_DETAILS">
	ancestors = <"Any", ...>
	properties = <
		["language"] = (P_BMM_SINGLE_PROPERTY) <
			name = <"language">
			type = <"Terminology_code">
			is_mandatory = <True>
		>

The BMM openehr_base_110.bmm is significantly more recent than the OPT 1.4 XSD. AFAIK, the XSD is is the currently use and correct way to process OPT 1.4 XML.

Semantically, there is no change in the use of Terminology_code, it does the same thing as CODE_PHRASE, but is not buried inside the Reference Model. Outside of the RM, Terminology_code is now used to represent a terminology code.

We refactored what is now the [Resource Model](https://We refactored) from an earlier version of the RM COmmon IM spec; you will see the newer Resource Model has extra fields etc.

It’s a bit annoying, especially when you come along afterward, so hopefully this helps a bit.

1 Like

Once you publish a question you “see” things that before went unseen :flushed:

I’ve noticed that Resource.xsd is using old RM release: RM/Release-1.0.2/BaseTypes.xsd

Actually the whole Resource.xsd is published as Release 1.4 but the file’s first line is <!-- openEHR Release 1.0.2 Resource XML schema -->.

In the RM release 1.0.2 the “language” is specified as CODE_PHRASE.

["TRANSLATION_DETAILS"] = <
  name = <"TRANSLATION_DETAILS">
  ancestors = <"Any", ...>
  properties = <
    ["language"] = (P_BMM_SINGLE_PROPERTY) <
      name = <"language">
      type = <"CODE_PHRASE">
      is_mandatory = <True>
1 Like

I’m afraid things in XSD-land might not exactly match the source specs, in terms of file-naming, etc, but as they are in constant use, I think they most likely correct; the problem is that if you come along without knowing the (hidden) history, it’s hard to magically know what gets used where. @sebastian.iancu did much of the work on cleaning up XSDs and could probably elaborate.

On the plus side, if you are looking to construct a new system or application based on openEHR, just use the latest published release of everything i.e. RM 1.1.0 and so on; don’t use any previous releases. Things should work fine if you do that. If you still find XSD (or BMM or any other) errors, please report them, either here, if you are not sure, or if you are sure of a problem, you can create an official PR (Problem Report) here on Jira.

1 Like

Thank you for the explanation @thomas.beale. That was super quick :sweat_smile:

I’ll implement the “language” element as type TERMINOLOGY_CODE in OPT 1.4 files. I guess the published Reference.xsd wasn’t re-generated and still refers to the old release.

1 Like

It is an adventure working with openEHR as a newcomer :sweat_smile:

CKMs export OPT files in the “original” release 1.0.2 format. I checked Clinical Knowledge Manager and Clinical Knowledge Manager.

Archie uses its ADL14Converter to convert templates to AOM release 2.0.6.

I’ll need to write a similar converter since I’m using Archie’s “openEHR_aom_206.bmm” to generate my AOM.

I guess CKMs still produce OPTs in a very old release 1.0.2 and tools are converting them to OPT2 for using them with a newer AOM2?

It would be so much easier if CKMs produced OPT2 :thinking:

But hey, I have a whole weekend to write OPT to AOM2 converter :upside_down_face:

That should be achievable from Archie, either from within CKM or in a local build.

It can also be generated from the ADL WB tool.

I can even run it locally on the latest copy of CKM and generate a full set of OPT2 files if you like.

@pieterbos has written an (as far as I know still experimental) OPT1.4 to OPT2 converter which sounds what you may want to have a look at. Something we’ll add to CKM as well in due course (but certainly not over the weekend)

Can the ADL Workbench generate OPT1.4 to OPT2 already, @thomas.beale (and not “only” convert adl1.4 to adl2 / opt2. The oets may be the remaining challenge?

What may be even more interesting is an OPT2 → OPT1.4 conversion, because quite likely most openEHR vendors will have to rely on OPT1.4 for a while.

I used public CKMs to download few OPTs for testing.

Thank you for offered help in generating OPT2 files but I don’t want to take your time.
…unless you have few of them ready on your disk :blush: :pray:
That would speed let me write OPT2 to AOM2 converter over the weekend and skip the OPT14.

Thank you for the explanation @sebastian.garde.

I’ll take a risk and skip support for OPT14 then. Eventualy CKMs will export OPT2 or users will be able to convert them with one of the tools.

1 Like

Welcome to the club of people who support ADL 2 natively! We’re still a small group unfortunately, but support to migrate is growing fast.

The OPT 1.4 → OPT 2 converter in Archie is feature complete, but has only had limited testing. It will work for at least some OPTs, and may give problems for others. Any issues found should be easy to fix. If you try it, please do report your results, including any issues you find, so the converter can be improved.

OPT2 is already fully AOM2, so I am not sure what you mean with ‘opt2 to aom 2 converter’. Converting OPT 1.4 to OPT 2 is quite a lot of work to get right, just directly importing the OPT 1.4 data into AOM 2 is much less work. The Archie branch that Sebastian pointed to contains the code for both processes.

2 Likes

Thank you @pieterbos for the OPT 1.4 to OPT 2 converter!

On my first review I saw a DEVELOPMENT status for OPT2 so I picked OPT 1.4 instead. I’m happy to join the ADL 2 club (now that I learned the OPT 1.4 is using the “original” RM release).

Everything else is already AOM 2 in my little project.

Its the part where I read the OPT(2) file and “convert” it to AOM classes in-memory.

Thank you for all the links and information to everybody.

I’ve (re)read OPT2 specifications and I could skip the “convert” part if I used OPT2 in JSON format (.optj). I could generate the serialize/deserialize code for the AOM2 classes from the AOM2 BMM. This would let me deserialize directly from the .optj file to the AOM2 in-memory classes. Zero code to maintain thanks to the BMM!

I’m reading through the “ADL Workbench (AWB) User Guide” to see how to create a few sample .optj files.
(if somebody has done this before and has these files, please send/upload them)

I went ahead and installed ADL Workbench on my Mac. That was an experience :sweat_smile:

If somebody tries doing the same:

  • Don’t install in the Documents folder.
  • Don’t skip the line “Then clone the iso8601 and error_message libraries into a directory such as …/EiffelHub/:” => create the EiffelHub directory before executing the last two “git clone” commands.

I was able to compile AWB but received 8 errors (they are actually only 1 error):

1 VCCH(1) Class has deferred feature(s), but is not declared as deferred. Check deferred feature yymax_symbol_equiv_class from class YY_SCANNER_SKELETON. ADL_14_2_REWRITER.yymax_symbol_equiv_class (adl_components)
...
CADL_14_SCANNER.yymax_symbol_equiv_class (adl_components)
ADL_14_SCANNER.yymax_symbol_equiv_class (adl_components)
BMM_TYPE_NAME_SCANNER.yymax_symbol_equiv_class (eomf_bmm)
OG_PATH_SCANNER.yymax_symbol_equiv_class (eomf_object_graph)
ODIN_SCANNER.yymax_symbol_equiv_class (eomf_odin)
ADL_2_SCANNER.yymax_symbol_equiv_class (adl_components)
CADL_2_SCANNER.yymax_symbol_equiv_class (adl_components)

I was brave enough to try to fix them. My first experience with Eiffel. No, I wasn’t successful.

Next, I installed the provided AWB EXE file on my Windows computer. I was able to open a template and save it as a .JSON file. It says it is an operational template but doesn’t use the .OPTJ extension as in OPT2 specifications. Well, it is good enough for me even with the .json.

I guess a can now generate serialize/deserialize support to the AOM2 classes. It will save me a lot of coding now and it will be future proof when specifications change.

It was a good day. Thank you to everybody who took the time to help :wave:

1 Like

I have to say, as the author of AWB, but who uses Windows and Linux, it works on both of those platforms, but to get it working on the Mac, which we did manage in the past, was very difficult, partly due to difficulty of getting GTK2 installed. Anyway, I might have saved you the trouble if I had known you were going to try that platform :wink:

I will however check the state of the source build; not many people do that, so it may be out of date with respect to the compiler version you probably installed (can you let me know which compiler version it was?).

Sorry for the annoyance - I’ll try to improve things there.

Don’t worry about the Mac. Windows and Linux is enough. I guess there are more important things on your ToDo list than making AWB run on a Mac for one person :blush:

I installed the Eiffel Studio successfully. The source build worked. Based on the compiler errors I thought that the deferred feature yymax_symbol_equiv_class was added to these classes and they were somehow not in sync with the change.

But it was the first time I saw an Eiffel code so I’m probably completely wrong here :sweat_smile:

I already deleted Eiffel Studio so I don’t know which compiler version was used. I guess the latest since I installed everything following the instructions from their site.