AOM node_id optionality rules not clear

Mandatory with void allowed does not seem useful to me. But having it optimal seems righ, although I can understand that it then must be optional in C_Object too, and become explicitly mandatory in C_Complex_Object, just to have it logical modeling style, (do not restrict further upwards in a scheme) however I am not sure about this last argument, because that rule applies to visibility

So the change would be to make it optional on Data_values (The C_objects that represent data_values) or to keep it mandatory with void allowed? Probably the change in the Data_value is still needed even if it is optional (I think any current domain type is transformed to alternatives of data_values right now).

@Heath Frankel I actually think adding archetype_node_id to DATA_VALUE is a less problematic idea than allowing multiple template ids on every node in data, which I think is complicated to specify, and will make it harder to reliably handle retrieved data. If there really is a need to know which DV_QUANTITY or whatever was used in the data, putting the node id on DATA_VALUE may make sense.

However.... ADL 2 tuples generally turn multiple DV_QUANTITY constraints into a single one with multiple tuple branches.

I think the original thrust of this PR was that the ADL 1.4 mandatory value for node_id needed to be addressed. So I think a CR coming from that has to be about rectifying that invariant / semantics in a sub-v2 version of ADL/AOM.

Diego makes a good point, unless the reference model allows a node-id to be stored on DATA_VALUE then there is not a lot of point of having them in the archetype as they can't be used to determin which constraint is to be used. However, this is only an issue when there is no other way to differentiate the constraint such as type. There are plenty of places where this is true, for example Ian's suggestion that he needs to specify multiple DV_QUANTITY constraints, when we have a choice of DV_TEXT and DV_CODED_TEXT and PARTICIPATION constraints.
The validator can do its best guess but there are cases where it just can't work out which constraint to use.
Don't get me wrong, I am not suggesting that we add node-id into DATA_VALUE, this would alienate any alignment with other datatype standards and I think we have enough metadata in the data already. We also need to make ADL to work for other RMs like 13606 where we won't have the option to add a node-id.
I have indicated previously that I think at codes are being overloaded for uniquely identifying node constants and the definition of a node concept. The ontology is getting polluted with clinically meaningless concepts just to uniquely identify a constraint.
I understand the need to uniquely identify a design-time constraint but this shouldn't get messed up with the identification of the concept in the data.
If we consider how CDA does this, they have a type code and a template id, the template id indicates the constraints used for this particular concept. Template ids are optional at any level and there can be multiples to allow support at different of the template constraint hierarchy.
I have been indicating that the ARCHETYPED class should support multiple template-ids to enable this template specialisation now that we have no way to derive the parent from the archetype/template ids.
Perhaps this idea should be supported on any node, not just archetyped nodes?

The 1.4 spec says that they are mandatory, but allows the 'unknown' value, which enables anonymous nodes. The back-end parser of the Archetype Editor synthesises these values during parsing, so technical, in memory, ADL 1.4 archetypes in that tool do not violate the specification.

However, it's not very useful, for obvious reasons, and ADL 2 fixes this. Fixing it in ADL 1.4 requires upgrading tools like the AE to say ADL 1.5 or 1.6, whichever we designate as the version that enforces this rule properly, and implements the same kind of id synthesis as done by the ADL Workbench.