# Why is the DV\_TEXT \<value\> element missing when mapping terminologies with ORDINAL?

**URL:** <https://discourse.openehr.org/t/why-is-the-dv-text-value-element-missing-when-mapping-terminologies-with-ordinal/11468>\
**Category:** ADL\
**Tags:** template\
**Created:** [1 October 2025 11:01 UTC](https://discourse.openehr.org/t/why-is-the-dv-text-value-element-missing-when-mapping-terminologies-with-ordinal/11468 "2025-10-01T11:01:19Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Yasitha\_Thilantha](https://discourse.openehr.org/user_avatar/discourse.openehr.org/yasitha_thilantha/32/5364_2.png) [@Yasitha\_Thilantha](https://discourse.openehr.org/u/Yasitha_Thilantha)\
**Post date:** [1 October 2025 11:01 UTC](https://discourse.openehr.org/t/why-is-the-dv-text-value-element-missing-when-mapping-terminologies-with-ordinal/11468/1 "2025-10-01T11:01:19Z")

</div>

I created an archetype with an **ORDINAL** attribute and mapped terminologies into the options. Using that archetype, I created a template and tried to validate it against the openEHR schema specifications.

During validation, I noticed that one mandatory element, `<value>` under **DV\_TEXT** , is missing. Both the archetype and template were created using the _Better Archetype Designer_ tool.

This is the validation error I got:  
‘value’ expected instead of ‘defining\_code’

 ![image](https://discourse.openehr.org/uploads/default/original/2X/2/2ed611ddd437be0767bcee3c58209e3588040c52.png)

Do you have any idea why this mandatory element is missing in the OPT file?

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [15 September 2026 12:48 UTC](https://discourse.openehr.org/t/why-is-the-dv-text-value-element-missing-when-mapping-terminologies-with-ordinal/11468/2 "2026-09-15T12:48:42Z")

</div>

I’m coming back to this - sorry we all missed it @Yasitha_Thilantha , as the issue has come back again, as part of FerroEHR

[OPT 1.4 export from Archetype Designer omits mandatory DV\_CODED\_TEXT.value on DV\_ORDINAL symbols — requesting confirmation · Issue #3395 · rubentalstra/FerroEHR · GitHub](https://github.com/rubentalstra/FerroEHR/issues/3395) reported by @Sophie

My gut feeling is that the .opt generated by AD is correct - we should not be adding the DV\_CODED\_TEXT/value constraint, as this is inherently language-neutral.

I think the problem is that the XSDs expect a full DV\_CODED\_TEXT in the context of ‘symbol’ - I can see that in similar situations, a C\_QUANTITY\_LIST openEHR profile has been created to allow 'magnitude` to be omitted.

I assume the same applies to DV\_SCALE

---

<div class="post-metadata">

**Author:** ![rubentalstra](https://discourse.openehr.org/user_avatar/discourse.openehr.org/rubentalstra/32/6546_2.png) [@rubentalstra](https://discourse.openehr.org/u/rubentalstra)\
**Post date:** [15 September 2026 14:44 UTC](https://discourse.openehr.org/t/why-is-the-dv-text-value-element-missing-when-mapping-terminologies-with-ordinal/11468/3 "2026-09-15T14:44:09Z")

</div>

@ian.mcnicoll thanks for picking this up again, and @Sophie thanks for the report on the FerroEHR tracker ([OPT 1.4 export from Archetype Designer omits mandatory DV\_CODED\_TEXT.value on DV\_ORDINAL symbols — requesting confirmation · Issue #3395 · rubentalstra/FerroEHR · GitHub](https://github.com/rubentalstra/FerroEHR/issues/3395)).

Ian, on the model we agree. AOM 1.4 defines `C_ORDINAL.list` as a list of `ORDINAL`, and `ORDINAL.symbol` is a `CODE_PHRASE` (Appendix A: “Terminology code providing the Ordinal’s symbol”). A code, no text. The rubric sits in `term_definitions`, per language, which is what `0|[local::at0005]` has meant since ADL 1.4.

The OPT 1.4 XML format is a different matter. Its only released definition is `OpenehrProfile.xsd` in AM/Release-1.4 (the same file in the 1.0.2 and 2.0.0 ITS-XML bundles). That schema serialises `C_DV_ORDINAL.list` and `assumed_value` as the RM type `DV_ORDINAL`, so the symbol is a `DV_CODED_TEXT` with a mandatory `value`. The schema already made `C_QUANTITY_ITEM.magnitude` optional for this exact reason and never did it for ordinals. Model and schema disagree, and a document without the element is invalid against the only definition the format has.

FerroEHR validates against that schema and accepts exactly what it admits. It refuses the Archetype Designer export and accepts the CKM one, because CKM writes an empty `<value/>` (valid: `xs:string`, empty allowed).

I have written the model/schema disagreement up on our tracker: [upstream(ITS-XML): OpenehrProfile.xsd requires DV\_CODED\_TEXT.value on a C\_DV\_ORDINAL symbol, while AOM 1.4 ORDINAL.symbol is a CODE\_PHRASE with no text · Issue #3401 · rubentalstra/FerroEHR · GitHub](https://github.com/rubentalstra/FerroEHR/issues/3401). It has not gone to the ITS-XML tracker yet. The fix would be your proposal: make `value` optional inside the profile for ordinal symbols, as `magnitude` already is, or model the list with an `ORDINAL`-shaped type whose symbol is a `CODE_PHRASE`. Both work with every OPT that already carries a rubric. Until then an OPT 1.4 exporter has to write `<value/>` the way CKM does.

@Yasitha_Thilantha, the validator you used was right about the released schema. The disagreement is between the schema and the model.

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [16 September 2026 10:02 UTC](https://discourse.openehr.org/t/why-is-the-dv-text-value-element-missing-when-mapping-terminologies-with-ordinal/11468/4 "2026-09-16T10:02:23Z")

</div>

Thanks Ruben,

I’ve done a bit more digging and a quick summary

1. The spec says that DV\_CODED\_TEXT/value is xs: string but the XSD says NoEmptyStrings so perhaps CKM’s output is not strictly legal.

2. The original spec has the DV\_ORDINAL list as DV\_CODED\_TEXT but this was subsequently updated to C\_CODE\_PHRASE and, in fact the BMM has an Ordinal class which is very close to what we were prposing for C\_ORDINAL\_ITEM.

3. I’m pretty sure that most ?none of the existing tools or CDRs are not using the .xsd to validate .opt files, otherwise this would have come to light earlier.

4. My guess is that the CKM .opt generation is based on code that predated the spec change while AD/ Archie and therefore Ehrbase are basically using BMM as the source of truth.

We should still get the XSD fixed as we know that it is valuable for other tooling but there is an argument to relax the XSD validation at template upload for your CDR. The XSD fixes might take a little time to figure out the best route to maintain backwards compatibility.

@sebastian.garde @sebastian.iancu @matijap @birger.haarbrandt any thoughts/advice re how.if .opts are validated at ingest via the REST API/ other tooling?

---

<div class="post-metadata">

**Author:** ![sebastian.iancu](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sebastian.iancu/32/31_2.png) [@sebastian.iancu](https://discourse.openehr.org/u/sebastian.iancu)\
**Post date:** [16 September 2026 16:46 UTC](https://discourse.openehr.org/t/why-is-the-dv-text-value-element-missing-when-mapping-terminologies-with-ordinal/11468/5 "2026-09-16T16:46:38Z")

</div>

I agree this an issue we will need to tackle. How exactly - I don’t know right now (there is a lot of information written above which I need to process), but is likely that the XSD are outdated, and the JSON-schemas are not reach enough. I would first make sure BMM is the way it shoudl be (if is not already). If we don’t have a SPECPR for this, can some one create it pleaae?

---

<div class="post-metadata">

**Author:** ![sebastian.garde](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sebastian.garde/32/3070_2.png) [@sebastian.garde](https://discourse.openehr.org/u/sebastian.garde)\
**Post date:** [18 September 2026 06:39 UTC](https://discourse.openehr.org/t/why-is-the-dv-text-value-element-missing-when-mapping-terminologies-with-ordinal/11468/6 "2026-09-18T06:39:44Z")

</div>

Like @sebastian.iancu, I have to admin that I am not sure I have processed the whole thread adequately yet, but would like to make the following preliminary general comments:

- It seems to me that having the value populated here with a localised text is redundant and introduces a language dependency on the opt which we don’t really want - nor need?

- Generally speaking, the (design time) opt cannot fulfill the (runtime) requirement that all mandatory elements exist and fulfill all constraints. Even if `value` is declared as mandatory (and non-empty), this cannot always mean it is mandatory in the archetype or template and thus opt. Take `DV_TEXT.value` or even `DV_CODED_TEXT.value`(as the data type of an element itself). You cannot (usually) fix them to a specific value at design time, even though they will be mandatory in data. If you take the data type constraints as the basis for validation, there will probably be no opt that validates?

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [19 September 2026 14:56 UTC](https://discourse.openehr.org/t/why-is-the-dv-text-value-element-missing-when-mapping-terminologies-with-ordinal/11468/7 "2026-09-19T14:56:15Z")

</div>

I think we agree on the issue and that the XSD should not demand a populated DV\_CODED\_TEXT.value

The Ocean .opt generator gets around this by creating

`<value> </value> `(a space)

which complies with the

`<xs:element name="value" type="NonEmptyString"/>` in DV\_TEXT.

The PDF specs say

 ![CleanShot 2026-09-18 at 21.21.48](https://discourse.openehr.org/uploads/default/original/2X/7/741ddc6fafc1100fbdd0e99ca0471e6c94fc0f25.png)

Which is IMO correct

and BMM

```yml
C_ORDINAL:
    name: C_ORDINAL
    documentation: 'Constrainer class for Ordinal data.'
    ancestors:
      - C_DOMAIN_TYPE
    properties:
      list: !P_BMM_CONTAINER_PROPERTY
        name: list
        documentation: 'Value set of allowed Ordinals in the constraint.'
        type_def:
          container_type: List
          type: ORDINAL
        cardinality:
          lower: 0
          upper_unbounded: true

ORDINAL:
    name: ORDINAL
    documentation: 'Constrainer object representing a single Ordinal value.'
    properties:
      symbol: !P_BMM_SINGLE_PROPERTY
        name: symbol
        documentation: "Terminology code providing the Ordinal's symbol."
        is_mandatory: true
        type: CODE_PHRASE
      value: !P_BMM_SINGLE_PROPERTY
        name: value
        documentation: 'Ordinal value.'
        is_mandatory: true
        type: Integer

```

We could change the XSD to match the BMM and spec definition which would allow the Better .opt to validate but the Ocean .opt would then fail, so I’m inclined to make the XSD a choice of DV\_CODED\_TEXT or ORDINAL to keep the Ocean approach valid in order to limit disruption.

DV\_SCALE has the same issue.

I’ll add CRs in JIRA and pull request in Github ITS-XML