In AOM.pdf is stated that node_id from C_OBJECT is mandatory. This is also confirmed in email on the technical mailinglist.
I think this is an error. I checked the Eifel-code:
set_node_id (an_object_id: STRING)
Object_id_valid: not an_object_id.is_empty
I think this means, that if it exists it must not be empty.
The same is in the Java-code, where it may be null, but if it is not null it may not be empty.
I don't know what the definition of mandatory is, but I think it says that it may not be null.
If this is the case, then there is an error in the SPECS, or an error in several software-projects, and also lots of errors in 99% of the CKM archetypes in which many C_Primitive_Objects (derived from CObject) occur, all without nodeId.
When this issue is based on misunderstanding, please forgive me.
But I was brought on the track of this issue by an email by Thomas Beale in which he states:
Quote:" I spent a bit of time trawling back through that last discussion on C_OBJECT.node_id (the property that carries at-codes) and whether it should be mandatory or optional, and also whether empty is valid.
Currently it is mandatory, and can't be empty."
This email has as title: "archetype node_ids again - looking for final solution" and has been send on 22 nov 2013.
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.
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?
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.
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).
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