We discussed on the list about the need of node_id for primitive contraints in the AOM to allow referencing alternatives in a constraint for ELEMENT.value.
That seems to be solved in the AOM 2, but was an issue from AOM 1.4.
If we need to create paths for an specific part of the structure that points to one of the alternatives, e.g. for querying, we don't have a place in the IM to store the node_id that will be one of the right-most ids in the path.
What we talked about, and most agreed, is to add a node_id to the DATA_VALUE class, or (my preference) to make DATA_VALUE inherit from LOCATABLE to have the archetype_node_id attribute in DATA_VALUE.
I'm pretty sure that just to have a correct specialization mechanism we need to have node id on the data types (if you can redefine them you should be able to precisely point to what is changed)
Putting node_id into the RM class DATA_VALUE would be a major change - we'd need to find out the impact of this on current vendor implementations - particularly for existing data, which I think would make it quite difficult. It seems odd that noone has asked for it before - my impression is that it isn't very important in the DV type objects. your implementation must be doing something different to the others - maybe more precise querying based on archetypes?
I am inclined to close this PR, unless the lack of a node id on DATA_VALUEs is really causing any real world problems.
Was discussed at SEC meeting 30 Sep 2019 Valencia.
we consider this change too high-impact to solve ?marginal problems.