I just finished reading all the old posts in the ADL category. There are few threads about ELEMENT with DV_CODED_TEXT and DV_TEXT for free text. Some observations after reading them all in a single sitting:

  • I noticied that nobody suggested a dedicated DV_CODED_TEXT_EXTENDED type (pick a better name). It would be DV_CODED_TEXT with an additional attribute (e.g. “free_text”).

  • Coded values would be in “defining_code” and the free text would be in “free_text” attribute. Edit: or “free_text” could be a boolean and the text would go into “value” as usually.

  • This is such a common scenario that a separate DV_ type might be reasonable.

  • There would be a single “id” for such a value. I hope that is OK from the AQL point of view.

  • UI component libraries usually support DV_CODED_TEXT_EXTENDED with a single component which is intuitive to the user and follows the intention of the modeler.

  • I might have missed some old email list discussions where a dedicated data value type was already dismissed.

Another observation - threads are discussing two different use cases:

  • Extending the lists for DV_CODED_TEXT with additional/different values (but still limiting the values to the list).

  • Using DV_TEXT for free text when the needed value is not in the list for DV_CODED_TEXT.

Summarized thread:

do you mean a free text field distinct from the inherited value field? The semantics of that is more like a term mapping on a DV_TEXT, which you can already do.

But maybe you meant something else?


DV_CODED_TEXT_EXTENDED.defining_code is used when the value is from the terminology.

In case a user cannot use any of the terms in the terminology it would enter the free text value into DV_CODED_TEXT_EXTENDED.free_text (or into DV_CODED_TEXT_EXTENDED.value and set DV_CODED_TEXT_EXTENDED.free_text = true).

Currently a single-valued attribute with alternative values:

ELEMENT[id6] occurrences matches {0..1} matches {    -- Result status
     value matches {
         DV_CODED_TEXT[id9005] occurrences matches {0..1} matches {
              defining_code matches {[ac9000]}    -- Result status (synthesised)
         DV_TEXT[id9006] occurrences matches {0..1} 

Using a new data value type DV_CODED_TEXT_EXTENDED:

ELEMENT[id6] occurrences matches {0..1} matches {    -- Result status
     value matches {
         DV_CODED_TEXT_EXTENDED[id9005] occurrences matches {0..1} matches {
              defining_code matches {[ac9000]}    -- Result status (synthesised)

Could this work?

It looks too simple. I must be missing something :thinking:

There have been a lot of of conversations on this - basically we can do this already via DV_TEXT/DV_CODED_TEXT but is a bit confusing so we have been looking to introduce the idea of term-binding strength in ADL/AOM2 which is much more explicit.

1 Like

Thanks to Borut reference I was re-reading the issue and possible solutions and wanted to come back to an old discussion:

If the best solution for a new requirement is a backwards incompatible change:

  1. Go with it!
  2. Version the spec representing the major semver change
  3. Specify a migration path from previous major version to the new version

That way we can keep up with new requirements and allow implementers to migrate code and data if they want to. We shouldn’t be stopping improvements because of backwards incompatibility. But we need to be sure the backwards incompatible change is THE BEST solution for the requirement after thorough analysis.

Another point is: we don’t have hard deadlines like software development, so we can take the time to design a new major version spec with the next batch of backwards incompatible changes, with all the migration guides, etc. etc., then implementers can implement their changes in their own time. Note this neither affects conformance, since conformance is verified against a version of the spec, new major version => no problem! still conformant with a previous major version spec.