The spec should have more descriptions of how SDMN can be used by the other languages. This might affect some SDMN structures.
BPMN Messages are similar to Data Objects. In a sense, they are the Data Objects between Pools. And they can have data structures as well.
The current Data Associations (as well as those in BPMN) allow mapping between two data structures. But there are situations where 2 or more structures should be mapped to another structure. This capability should be added to SDMN. This may involve some signification metamodel adjustments.
Various comments on the following propreties:
dataItemRef: QName: "... A DataItem can have only one of dataItemRef or ItemDefinitionRef as a set attribute. Neither of them is required, though ..."
ERROR? - I could not find ItemDefinitionRef within DataItem; perhaps it was meant to be ItemDefinition or metaDefinitionRef; ItemDefinition does contain ItemDefinitionRef.
locationRef : Location [0..*] A list of potential Locations for the DataItem.
MISSING: this provides no idea what kind of 'location' is meant here; there are technical possibilities in the descendant types, but it doesn't tell us the semantics - is the location a source-of-truth repository where an instance of the item is maintained? Locations of copies? Something else?
preAssignment : Assignment [0..1] Specifies an optional pre-assignment DMN Expression. The expression will provide values for one or more of the simple type itemComponents of the ItemDefinition set for the DataItem.
ERROR? I could not locate 'itemComponents' in the model - probably what is meant is DMN1-3 ItemDefinition.itemComponent (singular name, multiple cardinality).
Proposed change:
ItemDefinitionRef is referenced in DataItem.dataItemRef, but doesn't exist in the model. Correction needed somewhere.
DataItem.locationRef (possibly renamed as per SDMN-4) needs to be better defined. The current definition provides no idea what kind of 'location' is meant here; there are technical possibilities in the descendant types, but it doesn't tell us the semantics - is the location a source-of-truth repository where an instance of the item is maintained? Locations of copies? Something else? Without a clearer distinction between information entities and physical ones, this might be difficult to clarify.
DataItem.preAssignment and (other properties in the model - need to do a global search) refer to 'itemComponents', which is not defined in the model. Possibly what is meant is DMN1-3 ItemDefinition.itemComponent
SDMN ItemDefinition would seem to be a major extension of the DMN ItemDefinition class. It is documented as: "The itemDefinition element is the mechanism for providing the data structure of DataItems. It is contained within a SDMNDefinitions"
Since SDMN is intended to be a formalism for defining data models / items in a simple way (i.e. simpler than using UML), I would not expect it to contain classes that depend on anything in DMN. If DMN were being written now, I would suggest it would reference SDMN::ItemDefinition. If there are solid semantics for the split between SDMN::ItemDefinition and DMN::ItemDefinition, I would suggest they should be preserved by modelling both within SDMN, and making future versions of DMN refer to that.
The DMN form appears to model data items, rather than 'anything', which appears to be the scope of SDMN ItemDefinition. It is therefore not obvious to me that the inheritance is right. We might expect something more like:
ItemDefinition (abstract)
+--- DataItemDefinition (more or less the DMN version)
+--- XXXItemDefinition
where the XXXItemDefinition is various meta-classes representing e.g. document, class, - all the other kinds of itemKindRef, with appropriate meta-modelling attributes.