During resolutions of SCE-7 and SCE-96, the three elements RootElement, KindSet, and Kind have been accidentally set as concrete but should have been abstract. In general, all SCE elements should be abstract and then specialized by concrete elements defined by the languages that are based on SCE. Some exceptions to this include concrete DI elements and the Model Artifacts (e.g., Group), which can be directly used by other languages without specializations. But that is not the case for the three classes mentioned before.

In addition, the XSD complex types tModelArtifact, tBaseElement, tElementType, tTypedElement, and tAnnotation are not abstract although their corresponding element definitions and metamodel classes are abstract.

The description of the import element was copied from BPMN and contains information that are not appropriate to SCE, which is an infrastructure specification and not specific to any modeling language.
Note that this text was updated by SCE-36, but the update was not comprehensive enough

Theoretically, SCEDI should be able to be re-used by other BPM+ languages (e.g., SDMN) without the other language creating simple marker classes that do not extend the SCE classes. However, SCEDI was developed with abstract classes. If these classes were changed to concrete, the other languages can remove their unnecessary classes from their languages.

The Annotation class, an abstract class, is no longer necessary since Documentation and Category are no longer subclassing it. With only Attachment subclassing Annotation, it provides no value. It also adds additional structural overhead that is not needed. Further, using the name "Annotation" conflicts with downstream language PPMN that want to use it for an unrelated language element.

XSD Chapter Outdated with incorrect text that was copied from the DMN specification.

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.