I’m trying to test the differences between Ocean AE and and Better AD but can’t create an entry with an ITEM_LIST or ITEM_SINGLE in the AD.
Maybe there is someone with more experience in this tool than me that knows why those types are not available, or maybe I’m not finding them in the UI.
Thanks!
That is correct AD does not support anything other than ITEM_TREE - that was by consensus with the modelling community as we found that other ITEM_X options often became restrictive, and we stopped using anything other than ITEM_TREE in the Ocean AE.
Funfact: EHRbase also only supports item tree
@ian.mcnicoll thanks
OT: do you know why most modeling tools don’t allow to set the existence on attributes?
I think his was just an early design choice by Ocean, carried on by AD to make the tool clinically focussed and largely isolate clinical modellers from the underlying RM.
There are places where attribute level constraining might be helpful e.g mappings but I’m not sure I have ever felt the need ot apply existence constraints. In fact the opposite is more troublesome i.e no current way to make key RM attributes like OBS.time/origin visible in the data tree.
The strange thing is existence is mandatory by the specification, and though Ocean tools don’t allow to set it on archetypes or templates, it is exported on OPTs, though inconsistently because it is not in the composition context IIRC.
“Constraint on every attribute, regardless of whether it is singular or of a container type, which indicates whether its target object exists or not (i.e. is mandatory or not).”
The need of existence is to say if an attribute could or not be null, for instance in a multiple attribute like HISTORY.events you can specify the cardinality constraint (which is to say if the collection could be empty or not or if certain number of items are needed), then existence says if it’s valid to have a null collection. This separates the cases of null collection vs. empty collection. I do understand on the knowledge layer this difference might not be substantial, it’s a technical constraint. Though, knowing existence doesn’t allow nulls, means a system needs to consider that and instead of not sending certain attribute in, for instance, a JSON document, the attribute should be present. So for formal technical validation it is useful.
Maybe @thomas.beale can add more about this.
On the conformance validation side of things it’s difficult to verify current tools knowing that don’t implement things that are specified or as they are specified. I’m not against flexibility, but a thing vendor A does in a more ‘relaxed’ way can be different from what vendor B does in a ‘relaxed’ way, because bending the specs means getting away from formality and generating potential inconsistencies and interoperability problems.
