Shouldn’t that be stated somewhere in the specs?
In the conformance area, we need to verify what the spec allows, that means if the spec allows X but it doesn’t make any practical sense, we still need to give that as valid when testing conformance. Because if the spec allows it and one implementation didn’t realize something doesn’t make sense and implemented it as it was specified, then we need to give that implementation a PASS on those tests, we can’t say that is wrong if the spec allows it.
If it’s not an invariant, it could be a note we can reference from the conformance verification, like the UML allowing X, W, Z, and the note saying but W and Z shouldn’t be there. If this is not in the spec, then it is allowed and any implementation will pass with X, W and Z there.
IMO giving all the rules in the spec, without the need of implementers to figure out the rules themselves, is a better way to manage implementation complexity. This whole thread came because I was implementing this and considered the OBJECT_REF could point to anything by the RM 1.0.2 spec. Then in 1.1.0 it seems a rule was added to restrict the target to VERSIONED_OBJECT (which is an undocumented breaking change, see Detected a potential breaking change in Common IM that doesn't seem to be documented still with that extra constraint, VERSIONED_FOLDER and VERSIONED_EHR_STATUS are valid targets of the OBJECT_REF, so as an implementer I need to add code to actually support those extra types there, with less types I have less code (because in EHRServer and Atomik when you commit a FOLDER with items it checks the targets exists in the DB, and since VERSIONED_X are stored in different tables, I need different queries to check existence, see? more types == more code).