all attribute (C_ATTRIBUTE) nodes that have existence matches {0} (i.e. are logically removed) are removed
I doubt that this is wanted behavior.
For example, if an optional RM attribute is explicitly removed in an archetype or template, this information will be lost when generating the operational template. As the C_ATTRIBUTE node is removed, the attribute isn’t mentioned any more and will fall back to being optional as specified in the reference model.
I therefore think that this line and the corresponding bit in “3.3. Flattening” later on should be removed.
It depends on what is trying to be achieved. If the intention of logically removing the attribute is to really remove all the constraint objects below it, then I doubt if it matters that something could be added back in under that attribute at runtime.
OTOH, maybe the intention is really to say: you cannot instantiate this attribute within this kind of object, then you are right.
I think the first case is much more likely to occur than the second. Can anyone even think of an example where an attribute should be effectively removed at runtime?
Good catch though - I didn’t think of this case when I wrote that spec … maybe someone can come up with a use for the second case, in which case, retaining the C_ATTRIBUTE in the OPT would be better. But to do it properly there should be a different flag (and ADL syntax) - one that means: ‘any data in this attribute is invalid’.
Well the protocol and state attributes are common examples. The current way to make them not show up in a form on the screen is to set their existence to 0 in a template. If you then loose that constrained in the operational template, it doesn’t achieve the desired result.
There is a case to be made for using a ui specific form level tag for this instead of using a constraint on the template level. Because the intent is usually that the attribute isn’t a usual part of the dataset/form. It’s not usually the intent to prevent recording the attribute in any case.
But that also holds for template constraints on archetype nodes. There the pattern is similar: setting occurrences/cardinality to 0. Which I always found a bit of a conceptual mismatch for the reason above.
Additionally I think it breaks the golden rule in the constraint model that any downstream artefact conforms to any upstream artefact in the specialisation hierarchy.
So for now I’d be in favour of changing the spec in the way Jelte suggested. And in parallel we should look at detailing the semantics of a constraint.
Maybe something like a binding strength on a constraint? Like: hard exclude, exclude recommended, suggested exclude. Which can then be picked up by form editor apps or client apps deciding on whether or not to process that constraint. I’m a little worried this opens a can of worms with semantics being interpreted differently between implementations. But apparently we’re already there.
If that’s the intent, why not constrain out all the underlying constraint objects? And again I don’t understand how that’s acceptable, to remove constraints.
I think there are 2 possibilities, both of which are covered in ADL2.
Set existence to 0 to be explicit that a particular datapoint should definitely not be used, and make it unusable, by creating a validation error. I would use this rarely but I can see the value. Similarly, I can imagine cases where existence is changed to 1…1
2.Hide an RM attribute from developer guidance/ example compositions etc. Much more common and possible with the visibility marker in ADL2 , both to explicitly hide and explicitly show RM attributes in tooling etc. This is only a visualisation, it does not prevent or enforce usage.
Good point. What do the current tools do if the OPT has no ‘protocol’ attribute node (for example)? I thought it would still not show the protocol sub-tree. Do the current tools have a ‘show RM’ node that would show ‘protocol’?
Ok.
Need to think about the details, but I also had a similar idea.
Well, it’s not, but we’re talking about OPTs here which are a kind of output model, not a source model. But anyway, your (and Jelte’s) argument to adjust the semantics here seems sound.