We're updating the issue view to help you get more done. 

How to override ordering in specialised archetypes

Description

In the following example from the problem-diagnosis archetype, the AWB warns:
Warning (WCACA): attribute items in object node at /data/items[at0.35]/items cardinality 1..* same as in reference model.

CLUSTER[at0.35] occurrences matches {0..1} matches { – Diagnostic criteria
items cardinality matches {1..*; unordered} matches {
....
}
}

However, how can this be fixed?
The reference model states "ordered" as default in this case, and the creator of the archetype wanted it unordered for some reason.
Possible syntax could be (not currently legal):

  • items cardinality matches {unordered} or

  • items cardinality matches {; unordered}

Making a list unordered is relaxing a constraint in Thomas' and also my opinion, and should be illegal; and in any case, if the intention is for the list to be 'unordered', then any order that exists is by definition ok. The problem might be in GUI processing if some layer of software wanted to read the archetype and determine whether to impose ordering or not.

Now, if there were places in the RM where 'unordered' was the default, it should be legal to narrow this to 'ordered', and the parser would need a way to deal with this.

So the questions are:

  • should the RM have ordered as a default?

  • what should the ADL look like for doing unordered -> ordered?

  • what should the AOM look like for the above constraint?

Ian also thinks that the concept of 'ordered' needs a bit of a rethink. He is aware of only a few instances of clinical concepts that MUST be ordered at archetype level, although there are more situations of ordered being applied at template level. Having said that, most archetypes and lists do have a 'natural order' which should not be disturbed if at all possible, as it helps the review and sign-off process and is a sensible start point for UI ordering of elements, terms etc. Therefore, in his opinion, 'ordered ' should not be an RM default but any design-time ordering should be honoured by tools and at run-time unless specifically overriden at run-time or in a template/specialisation and 'ordered' applied.
Heather also argues that a default of unordered makes sense, constraining to ordered when neccessary and that at the moment it is not possible to legally have unordered at all.

Environment

None

Change Description

None

Impact Analysis

None

Status

Assignee

Unassigned

Reporter

Sebastian Garde

Components

Affects versions

AM version 1.4

Priority

Minor